Internet Engineering Task Force (IETF) A. DeKok, Ed.
Request for Comments: 6158 FreeRADIUS
BCP: 158 G. Weber
Category: Best Current Practice Individual Contributor
ISSN: 2070-1721 March 2011
RADIUS Design Guidelines
Abstract
抽象
This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, within the IETF as well as other Standards Development Organizations (SDOs).
このドキュメントでは、ユーザーサービス（RADIUS）プロトコルでリモート認証ダイヤルで使用される属性を設計するためのガイドラインを提供します。これらのガイドラインは、IETFだけでなく、他の標準開発機関（SDOの）中に、将来のRADIUS属性仕様の著者と査読に役立つことが期待されます。
Status of This Memo
このメモのステータス
This memo documents an Internet Best Current Practice.
このメモはインターネット最も良い現在の練習を説明します。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 BCPの詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6158.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6158で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Requirements Language ......................................4
1.3. Applicability ..............................................5
1.3.1. Reviews .............................................5
2. Guidelines ......................................................6
2.1. Data Types .................................................8
2.2. Vendor Space ...............................................9
2.3. Service Definitions and RADIUS .............................9
2.4. Translation of Vendor Specifications ......................10
3. Rationale ......................................................11
3.1. RADIUS Operational Model ..................................11
3.2. Data Model Issues .........................................14
3.2.1. Issues with Definitions of Types ...................15
3.2.2. Tagging Mechanism ..................................16
3.2.3. Complex Data Types .................................16
3.2.4. Complex Data Type Exceptions .......................18
3.3. Vendor Space ..............................................19
3.3.1. Interoperability Considerations ....................20
3.3.2. Vendor Allocations .................................20
3.3.3. SDO Allocations ....................................20
3.4. Polymorphic Attributes ....................................21
4. IANA Considerations ............................................22
5. Security Considerations ........................................22
5.1. New Data Types and Complex Attributes .....................23
6. References .....................................................24
6.1. Normative References ......................................24
6.2. Informative References ....................................24
Appendix A. Design Guidelines Checklist ..........................27
A.1. Types Matching the RADIUS Data Model ......................27
A.1.1. Transport of Basic Data Types ........................27
A.1.2. Transport of Authentication and Security Data ........27
A.1.3. Opaque Data Types ....................................27
A.1.4. Pre-existing Data Types ..............................28
A.2. Improper Data Types .......................................28
A.2.1. Simple Data Types ....................................28
A.2.2. More Complex Data Types ..............................29
A.3. Vendor-Specific Formats ...................................29
A.4. Changes to the RADIUS Operational Model ...................30
A.5. Allocation of Attributes ..................................31
Appendix B. Complex Attributes ...................................32
B.1. CHAP-Password .............................................32
B.2. CHAP-Challenge ............................................32
B.3. Tunnel-Password ...........................................33
B.4. ARAP-Password .............................................33
B.5. ARAP-Features .............................................34
B.6. Connect-Info ..............................................34
B.7. Framed-IPv6-Prefix ........................................35
B.8. Egress-VLANID .............................................36
B.9. Egress-VLAN-Name ..........................................37
B.10. Digest-* .................................................37
Acknowledgments ...................................................37
This document provides guidelines for the design of Remote Authentication Dial In User Service (RADIUS) attributes within the IETF as well as within other Standards Development Organizations (SDOs). By articulating RADIUS design guidelines, it is hoped that this document will encourage the development and publication of high-quality RADIUS attribute specifications.
この文書では、他の標準開発機関（SDOの）内IETF内の属性だけでなく、ユーザーサービス（RADIUS）でリモート認証ダイヤルのデザインのためのガイドラインを提供します。 RADIUS設計ガイドラインを明確することで、この文書は、高品質なRADIUS属性の仕様の開発と出版を奨励することが期待されます。
However, the advice in this document will not be helpful unless it is put to use. As with "Guidelines for Authors and Reviewers of MIB Documents" [RFC4181], it is expected that authors will check their document against the guidelines in this document prior to publication or requesting review (such as an "Expert Review" described in [RFC3575]). Similarly, it is expected that this document will be used by reviewers (such as WG participants or the Authentication, Authorization, and Accounting (AAA) Doctors [DOCTORS]), resulting in an improvement in the consistency of reviews.
使用することが置かれていない限りしかし、この文書のアドバイスは有益ではありません。 [RFC4181]「著者とMIBドキュメントの査読のためのガイドライン」のように、著者はこの文書のガイドライン出版前にまたはそのように記載された「エキスパートレビュー」として見直しを（要求に対して、そのドキュメントをチェックすることが期待される[RFC3575] ）。同様に、この文書は、レビューの一貫性を向上させること、（例えば、WG参加者または認証、許可、アカウンティング（AAA）医師[DOCTORS]など）レビューで使用されることが期待されます。
In order to meet these objectives, this document needs to cover not only the science of attribute design but also the art. Therefore, in addition to covering the most frequently encountered issues, this document explains some of the considerations motivating the guidelines. These considerations include complexity trade-offs that make it difficult to provide "hard and fast" rules for attribute design. This document explains those trade-offs through reviews of current attribute usage.
これらの目標を達成するためには、この文書には、属性のデザインの科学だけでなく、芸術だけでなく、をカバーする必要があります。そのため、最も頻繁に遭遇する問題をカバーに加えて、この文書は、ガイドラインをやる気に配慮のいくつかを説明します。これらの考慮事項は、それが困難な属性のデザインのための「厳格な」ルールを提供することを可能にする複雑さのトレードオフがあります。この文書では、現在の属性の使用方法のレビューを通じて、これらのトレードオフを説明します。
The rest of the document is organized as follows. Section 1 discusses the applicability of the guidelines and defines a recommended review process for RADIUS specifications. Section 2 defines the design guidelines in terms of what is "RECOMMENDED" and "NOT RECOMMENDED". Section 3 gives a longer explanation of the rationale behind the guidelines given in the previous section. Appendix A repeats the guidelines in a "checklist" format. Appendix B discusses previously defined attributes that do not follow the guidelines.
次のように文書の残りの部分は組織化されています。第1節は、ガイドラインの適用可能性を説明し、RADIUS仕様の推奨レビュープロセスを定義します。第2節では、「推奨」と「推奨しない」されたものに関して設計ガイドラインを定義します。第3節では、前節で与えられたガイドラインの理論的根拠の長い説明を提供します。付録Aは、「チェックリスト」形式のガイドラインを繰り返します。付録Bは、ガイドラインに従わない以前に定義された属性について説明します。
Authors of new RADIUS specifications can be compliant with the design guidelines by working through the checklists given in Appendix A. Reviewers of RADIUS specifications are expected to be familiar with the entire document.
RADIUS仕様の付録A.査読に与えられたチェックリストによる作業によって設計ガイドラインに準拠することができ、新たなRADIUS仕様の作成者は、文書全体に精通していることが期待されています。
This document uses the following terms:
このドキュメントでは、次の用語を使用しています：
Network Access Server (NAS) A device that provides an access service for a user to a network.
ネットワークアクセスサーバ（NAS）ネットワークへのユーザのアクセスサービスを提供する装置。
RADIUS server A RADIUS authentication, authorization, and accounting (AAA) server is an entity that provides one or more AAA services to a NAS.
RADIUSサーバは、RADIUS認証、許可、アカウンティング（AAA）サーバは、NASへの1つ以上のAAAサービスを提供するエンティティです。
Standard space Codes in the RADIUS Attribute Type Space that are allocated by IANA and that follow the format defined in Section 5 of RFC 2865 [RFC2865].
標準空間IANAによって割り当てられるRADIUS属性タイプ空間におけるコードとそれは、RFC 2865のセクション5 [RFC2865]で定義されたフォーマットに従います。
Vendor space The contents of the Vendor-Specific Attribute (VSA), as defined in [RFC2865], Section 5.26. These attributes provide a unique attribute type space in the "String" field for each vendor (identified by the Vendor-Type field), which they can self-allocate.
ベンダースペース[RFC2865]で定義されるように、ベンダー固有の属性（VSA）の内容、セクション5.26。これらの属性は、彼らが自己割り当てることができます（ベンダー-Typeフィールドによって識別される）各ベンダーのための「文字列」フィールドに一意の属性タイプのスペースを提供しています。
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 advice in this document applies to RADIUS attributes used to encode service-provisioning, authentication, or accounting data based on the attribute encodings and data formats defined in RFC 2865 [RFC2865], RFC 2866 [RFC2866], and subsequent RADIUS RFCs.
この文書に記載されているアドバイスは、RADIUSに適用されるサービスプロビジョニング、認証、またはRFC 2865 [RFC2865]で定義された属性のエンコーディング及びデータフォーマットに基づいて、会計データ、RFC 2866 [RFC2866]、およびその後のRADIUSのRFCを符号化するために使用される属性。
Since this document represents a Best Current Practice, it does not update or deprecate existing standards. As a result, uses of the terms "MUST" and "MUST NOT" are limited to requirements already present in existing documents.
この文書は現在のベストプラクティスを表しているので、それが更新または既存の基準を廃止しません。その結果、用語の「MUST」を使用し、既存の文書に既に存在している要件に限定されている「てはなりません」。
It is RECOMMENDED that these guidelines be followed for all new RADIUS specifications, whether they originate from a vendor, an SDO, or the IETF. Doing so will ensure the widest possible applicability and interoperability of the specifications, while requiring minimal changes to existing systems. In particular, it is expected that RADIUS specifications requesting allocation within the standard space will follow these guidelines and will explain why this is not possible if they cannot.
これらのガイドラインは、彼らは、ベンダー、SDO、またはIETFから発信するかどうか、すべての新しいRADIUSの仕様については、従うことが推奨されます。既存システムへの最小限の変更を必要としながら、そうすることで、仕様の可能な限り幅広い適用性と相互運用性を確保します。特に、標準的な空間内で割り当てを要求RADIUSの仕様は、次のガイドラインに従いますし、彼らができない場合はこれが不可能である理由を説明することが期待されます。
However, there are situations in which vendors or SDOs can choose not to follow these guidelines without major consequences. As noted in Section 5.26 of [RFC2865], Vendor-Specific Attributes (VSAs) are "available to allow vendors to support their own extended Attributes not suitable for general usage". Where vendors or SDOs develop specifications "not suitable for general usage", limited interoperability and inability to use existing implementations may be acceptable, and, in these situations, vendors and SDOs MAY choose not to conform to these guidelines.
しかし、ベンダーやSDOの大きな影響なしに、これらのガイドラインに従うしないことを選択することができている状況があります。 [RFC2865]、ベンダー固有アトリビュート（VSA）のセクション5.26に記載されているように、「ベンダーは一般的な使用には適していない独自の拡張属性をサポートすることを可能にするために利用可能」です。ベンダーやSDOのは、これらの状況、ベンダーとのSDOで、限られた相互運用性と許容できる既存の実装を使用できないこと、そして、「一般的な使用には適していません」の仕様を開発する場合は、これらのガイドラインに適合しないこともできます。
Note that the RADEXT WG is currently (as of 2011) involved in developing updates to RADIUS. Those updates will provide their own usage guidelines that may modify some of the guidelines defined here, such as defining new data types, practices, etc.
RADEXT WGは、（2011年現在）現在、RADIUSへのアップデートの開発に関与していることに注意してください。これらのアップデートは、など新しいデータ型、プラクティスを、定義など、ここで定義されたガイドラインの一部を変更することがあり、自分の使用ガイドラインを提供します
RADIUS protocol changes, or specification of attributes (such as Service-Type), that can, in effect, provide new RADIUS commands require greater expertise and deeper review, as do changes to the RADIUS operational model. As a result, such changes are outside the scope of this document and MUST NOT be undertaken outside the IETF.
（そのようなサービスタイプなど）RADIUSプロトコルの変更、または属性の仕様、それは、実際には、RADIUS運用モデルへの変更がそうであるように、新しいRADIUSコマンドは、より高い専門知識と深い検討が必要に提供することができます。結果として、そのような変更は、この文書の範囲外であり、IETFの外に行われてはいけません。
For specifications utilizing attributes within the standard space, conformance with the design guidelines in this document is expected unless a good case can be made for an exception. Reviewers SHOULD use the design guidelines as a review checklist.
良い場合は、例外のために行うことができない限り、標準スペース内の属性を利用仕様については、このドキュメントの設計ガイドラインに適合が期待されています。レビュアーは、レビューチェックリストとして設計ガイドラインを使用すべきです。
While not required, IETF review may also be beneficial for specifications utilizing the vendor space. Experience has shown that attributes not originally designed for general usage can subsequently garner wide-spread deployment. An example is the Vendor-Specific Attributes defined in [RFC2548], which have been widely implemented within IEEE 802.11 Access Points.
必須ではありませんが、IETFレビューもベンダーの空間を利用仕様に有益である可能性があります。経験はもともと、その後広く普及展開を集めることができ、一般的な使用のために設計されていない属性が示されています。例えば、広くIEEE 802.11アクセスポイント内に実装されている[RFC2548]で定義されたベンダー固有の属性です。
In order to assist in the development of specifications conforming to these guidelines, authors can request review by sending an email to the AAA Doctors [DOCTORS] or equivalent mailing list. The IETF Operations & Management Area Directors will then arrange for the review to be completed and posted to the AAA Doctors mailing list [DOCTORS], RADEXT WG mailing list, or other IETF mailing lists. Since reviews are handled by volunteers, responses are provided on a best-effort basis, with no service-level guarantees. Authors are encouraged to seek review as early as possible, so as to avoid potential delays.
これらのガイドラインに準拠した仕様の開発を支援するために、著者は、AAA医師[DOCTORS]または同等のメーリングリストに電子メールを送信することにより、審査をリクエストすることができます。レビューが完了し、リスト[DOCTORS]を郵送AAA医師に掲載されるためにIETF操作と管理領域取締役は、その後、RADEXT WGメーリングリスト、または他のIETFメーリングリストを手配します。レビューはボランティアによって処理されるので、応答が無いサービスレベルの保証で、ベストエフォートベースで提供されています。著者は、潜在的な遅延を避けるために、可能な限り早期に審査を求めることが奨励されます。
As reviewers require access to the specification, vendors and SDOs are encouraged to make it publicly available. Where the RADIUS specification is embedded within a larger document that cannot be made public, the RADIUS attribute and value definitions can be made available on a public web site or can be published as an Informational RFC, as with [RFC4679].
レビューアが仕様へのアクセスを必要として、ベンダーとのSDOはそれを公に利用可能にすることをお勧めします。 RADIUSの仕様は公開されてすることができない大きな文書内に埋め込まれている場合は、RADIUS属性と値の定義は、公開ウェブサイト上で利用可能にすることができますか[RFC4679]のように、情報のRFCとして公開することができます。
The review process requires neither allocation of attributes within the standard space nor publication of an RFC. Requiring SDOs or vendors to rehost VSAs into the standard space solely for the purpose of obtaining review would put pressure on the standard space and may be harmful to interoperability since it would create two ways to provision the same service. Rehosting may also require changes to the RADIUS data model, which will affect implementations that do not intend to support the SDO or vendor specifications.
レビュープロセスは、RFCの標準スペースやパブリケーション内の属性のどちらも割り当てが必要です。単に審査を得るための標準的な空間にVSAをリホストするためのSDOまたはベンダーを要求することは、標準的なスペースに圧力をかけることになり、それが提供する二つの方法と同様のサービスを作成しますので、相互運用性に有害かもしれません。再ホスティングもSDOまたはベンダーの仕様をサポートするつもりはないの実装に影響を与えるであろう、RADIUSデータモデルへの変更が必要な場合があります。
Similarly, vendors are encouraged to make their specifications publicly available, for maximum interoperability. However, it is not necessary for a vendor to request publication of a VSA specification as an RFC.
同様に、ベンダーは、最大限の相互運用性のために、その仕様を公開することが奨励されています。しかし、RFCとしてVSA仕様の公開を要求するベンダーのために必要ではありません。
The RADIUS protocol as defined in [RFC2865] and [RFC2866] uses elements known as attributes in order to represent authentication, authorization, and accounting data.
[RFC2865]及び[RFC2866]で定義されるようにRADIUSプロトコルは、認証、許可、およびアカウンティングデータを表現するために、属性として知られている要素を使用します。
Unlike Simple Network Management Protocol (SNMP), first defined in [RFC1157] and [RFC1155], RADIUS does not define a formal data definition language. The data type of RADIUS attributes is not transported on the wire. Rather, the data type of a RADIUS attribute is fixed when an attribute is defined. Based on the RADIUS attribute type code, RADIUS clients and servers can determine the data type based on pre-configured entries within a data dictionary.
最初の[RFC1157]と[RFC1155]で定義された簡易ネットワーク管理プロトコル（SNMP）とは異なり、RADIUSは、正式なデータ定義言語を定義するものではありません。 RADIUSのデータ・タイプは、ワイヤ上で輸送されない属性。属性が定義されている場合むしろ、RADIUS属性のデータ・タイプが固定されています。 RADIUS属性タイプコードに基づいて、RADIUSクライアントとサーバーは、データ・ディクショナリ内で事前に設定したエントリに基づいてデータ型を決定することができます。
To explain the implications of this early RADIUS design decision, we distinguish two kinds of data types, namely "basic" and "complex". Basic data types use one of the existing RADIUS data types as defined in Section 2.1, encapsulated in a [RFC2865] RADIUS attribute or in a [RFC2865] RADIUS VSA. All other data formats are "complex types".
この初期のRADIUSの設計上の決定の影響を説明するために、我々は、データ型の2種類、すなわち「基本」と「複合体」区別する。 [RFC2865] RADIUS属性または[RFC2865] RADIUS VSAの中にカプセル化セクション2.1で定義されるような基本的なデータタイプは、既存のRADIUSデータ型のいずれかを使用します。他のすべてのデータ形式は、「複合型」です。
RADIUS attributes can be classified into one of three broad categories:
RADIUS属性は、3つの大きなカテゴリーの一つに分類することができます。
* Attributes that are of interest to a single vendor, e.g., for a product or product line. Minimal cross-vendor interoperability is needed.
*製品または製品ラインのために、例えば、単一のベンダーにとって関心のある属性。最小限のクロスベンダーの相互運用性が必要とされています。
Vendor-Specific Attributes (VSAs) are appropriate for use in this situation. Code-point allocation is managed by the vendor with the vendor space defined by their Private Enterprise Number (PEN), as given in the Vendor-Id field.
ベンダー固有アトリビュート（VSA）このような状況での使用に適しています。ベンダーIDフィールドに与えられたように、コード・ポイントの割り当ては、彼らのプライベートエンタープライズ番号（PEN）で定義されたベンダーのスペースを持つベンダーによって管理されています。
* Attributes that are of interest to an industry segment, where an SDO defines the attributes for that industry. Multi-vendor interoperability within an industry segment is expected.
* SDOは、その業界の属性を定義する業界セグメント、に興味がある属性。業界セグメント内のマルチベンダーの相互運用性が期待されています。
Vendor-Specific Attributes (VSAs) MUST be used. Code-point allocation is managed by the SDO with the vendor space defined by the SDO's PEN rather than the PEN of an individual vendor.
ベンダー固有の属性（VSA）を使用しなければなりません。コードポイントの割り当ては、SDOのPENではなく、個々のベンダーのPENによって定義されたベンダーのスペースとSDOによって管理されています。
* Attributes that are of broad interest to the Internet community. Multi-vendor interoperability is expected.
*インターネットコミュニティへの幅広い関心のある属性。マルチベンダーの相互運用性が期待されています。
Attributes within the standard space are appropriate for this purpose and are allocated via IANA as described in [RFC3575]. Since the standard space represents a finite resource, and is the only attribute space available for use by IETF working groups, vendors, and SDOs are encouraged to utilize the vendor space rather than request allocation of attributes from the standard space. Usage of attribute type codes reserved for standard attributes is considered antisocial behavior and is strongly discouraged.
標準スペース内の属性は、この目的のために適切であり、[RFC3575]に記載されているようにIANAを介して割り当てられています。標準のスペースは有限の資源であり、IETFワーキンググループ、ベンダーで使用できる唯一の属性の空間であり、SDOのは、標準的な空間からの属性のベンダースペースではなく、要求の割り当てを利用することが奨励されているので。標準の属性のために予約属性タイプコードの使用法は、反社会的行動とみなされ、強くお勧めします。
RADIUS defines a limited set of data types, defined as "basic data types". The following data qualifies as "basic data types":
RADIUSは、「基本データ型」として定義されたデータタイプの限られたセットを定義します。以下のデータは、「基本データ型」としての資格：
* 32-bit unsigned integer in network byte order.
*ネットワークバイト順に32ビット符号なし整数。
* Enumerated data types, represented as a 32-bit unsigned integer with a list of name to value mappings (e.g., Service-Type).
*値のマッピング（例えば、サービスタイプ）に名前のリストを32ビットの符号なし整数として表されるデータ型を、列挙。
* IPv4 address in network byte order.
*ネットワークバイトオーダーでのIPv4アドレス。
* Time as a 32-bit unsigned value in network byte order and in seconds since 00:00:00 UTC, January 1, 1970.
* 00:00:00、1970年1月1日以来、ネットワークバイト順で32ビットの符号なしの値として、秒での時間。
* IPv6 address in network byte order.
*ネットワークバイトオーダーでのIPv6アドレス。
* Interface-Id (8-octet string in network byte order).
*インターフェイスID（ネットワークバイト順の8オクテット文字列）。
* IPv6 prefix.
* IPv6プレフィックス。
* String (i.e., binary data), totaling 253 octets or less in length. This includes the opaque encapsulation of data structures defined outside of RADIUS. See also Appendix A.1.3 for additional discussion.
*文字列（すなわち、バイナリデータ）、長さが253オクテット以下合計。これは、RADIUSの外部で定義されたデータ構造の不透明なカプセル化を含んでいます。付録A.1.3は、追加の議論についても参照してください。
* UTF-8 text [RFC3629], totaling 253 octets or less in length.
長さが253オクテット以下合計* UTF-8テキスト[RFC3629]。
Note that the length limitations for VSAs of type String and Text are less than 253 octets, due to the additional overhead of the Vendor-Specific encoding.
String型とテキストのVSAのための長さの制限は、ベンダー固有の符号化の追加のオーバーヘッドに起因未満253個のオクテットであることに留意されたいです。
The following data also qualifies as "basic data types":
以下のデータはまた、「基本データ型」としての資格：
* Attributes grouped into a logical container using the [RFC2868] tagging mechanism. This approach is NOT RECOMMENDED (see Section 3.2.2) but is permissible where the alternatives are worse.
* [RFC2868]タグ付け機構を使用して論理コンテナにグループ化属性。このアプローチは、推奨（セクション3.2.2を参照）が、選択肢が悪化しているところ許されていません。
* Attributes requiring the transport of more than 253 octets of Text or String data. This includes the opaque encapsulation of data structures defined outside of RADIUS, e.g., EAP-Message.
*テキストや文字列データの以上253オクテットの輸送を必要とする属性。これは、RADIUSの外に定義されたデータ構造、例えば、EAP-メッセージの不透明なカプセル化を含みます。
All other data formats (including nested attributes) are defined to be "complex data types" and are NOT RECOMMENDED for normal use. Complex data types MAY be used in situations where they reduce complexity in non-RADIUS systems or where using the basic data types would be awkward (such as where grouping would be required in order to link related attributes). Since there are no "hard and fast" rules for where complexity is best located, each situation has to be decided on a case-by-case basis. Examples of this trade-off are discussed in Appendix B. Where a complex data type is selected, an explanation SHOULD be offered as to why this was necessary.
（ネストされた属性を含む）すべての他のデータ形式は、「複雑なデータ型」であると規定されており、通常の使用にはお勧めしません。複合データ型は、それらが非RADIUSシステムに複雑さを軽減又は基本データ型を使用して（例えば、グループ化は関連の属性をリンクするために必要とされる場合など）、厄介であろう状況で使用されるかもしれません。複雑さが最高の置かれている場所には「厳格な」ルールが存在しないので、それぞれの状況は、ケースバイケースで決定する必要があります。このトレードオフの実施例は、複合データ型を説明では、これが必要であった理由として提供されるべき、選択された付録Bに記載されています。
The Vendor space is defined to be the contents of the Vendor-Specific Attribute ([RFC2865], Section 5.26) where the Vendor-Id defines the space for a particular vendor, and the contents of the "String" field define a unique attribute type space for that vendor. As discussed there, it is intended for vendors and SDOs to support their own attributes not suitable for general use.
ベンダー空間は、ベンダーIDは、特定のベンダーのための空間を画定するベンダー固有の属性（[RFC2865]、セクション5.26）の内容であると定義され、「文字列」フィールドの内容は、固有の属性タイプを定義しますそのベンダーのためのスペース。そこに述べたように、一般的な使用には適さない独自の属性をサポートするために、ベンダーとのSDOを対象としています。
While the encoding of attributes within the vendor space is under the control of vendors and SDOs, following the guidelines described here is advantageous since it enables maximum interoperability with minimal changes to existing systems.
ベンダー空間内の属性のエンコーディングは、ベンダーとのSDOの制御下にあるが、それは、既存のシステムに最小限の変更で最大の相互運用性を可能にするので、ここで説明したガイドラインに従うことは有利です。
For example, RADIUS server support for new attributes using "basic data types" can typically be accomplished by editing a RADIUS dictionary, whereas "complex data types" typically require RADIUS server code changes, which can add complexity and delays in implementation.
「複雑なデータ型は、」一般的な実装に複雑さと遅延を追加することができRADIUSサーバコードの変更を必要とし、一方、例えば、「基本データ型」を使用して、新しい属性のRADIUSサーバのサポートは、一般的に、RADIUS辞書を編集することによって達成することができます。
Vendor RADIUS Attribute specifications SHOULD self-allocate attributes from the vendor space rather than request an allocation from within the standard space.
ベンダーRADIUS属性の仕様は、標準的な空間の中から割り当てベンダー空間からではなく、要求属性を自己割り当てなければなりません。
VSA encodings that do not follow the [RFC2865], Section 5.26 encoding scheme are NOT RECOMMENDED. Although [RFC2865] does not mandate it, implementations commonly assume that the Vendor Id can be used as a key to determine the on-the-wire encoding of a VSA. Vendors therefore SHOULD NOT use multiple encodings for VSAs that are associated with a particular Vendor Id. A vendor wishing to use multiple VSA encodings SHOULD request one Vendor Id for each VSA encoding that they will use.
[RFC2865]、セクション5.26符号化方式に従わないVSAエンコーディングが推奨されていません。 [RFC2865]は、それを強制しませんが、実装は一般ベンダーIdがVSAのオン・ザ・ワイヤエンコーディングを決定するためのキーとして使用することができると仮定する。ベンダーは、したがって、特定のベンダーIDに関連付けられているVSAのための複数のエンコーディングを使用しないでください。複数のVSAエンコーディングを使用したいベンダーは、彼らが使用する各VSA符号化のために1ベンダーイドを要求すべきです。
RADIUS specifications define how an existing service or protocol can be provisioned using RADIUS, usually via the Service-Type Attribute. Therefore, it is expected that a RADIUS attribute specification will reference documents defining the protocol or service to be provisioned. Within the IETF, a RADIUS attribute specification
RADIUSの仕様は通常、service-type属性を経由して、既存のサービスやプロトコルがRADIUSを使用してプロビジョニングする方法を定義します。したがって、RADIUS属性指定をプロビジョニングするプロトコルやサービスを定義する文書を参照することが期待されます。 IETF、RADIUS属性指定の中で
SHOULD NOT be used to define the protocol or service being provisioned. New services using RADIUS for provisioning SHOULD be defined elsewhere and referenced in the RADIUS specification.
プロビジョニングされているプロトコルやサービスを定義するために使用しないでください。プロビジョニングのためにRADIUSを使用して新しいサービスは他の場所で定義されており、RADIUS仕様で参照されるべきである（SHOULD）。
New attributes, or new values of existing attributes, SHOULD NOT be used to define new RADIUS commands. RADIUS attributes are intended to:
新しい属性、または既存の属性の新しい値は、新しいRADIUSコマンドを定義するために使用されるべきではありません。 RADIUS属性がに意図されています。
* authenticate users
*認証ユーザー
* authorize users (i.e., service provisioning or changes to provisioning)
*許可ユーザ（すなわち、サービスプロビジョニングまたはプロビジョニングへの変更）
* account for user activity (i.e., logging of session activity)
*ユーザの活動のためのアカウント（すなわち、セッション・アクティビティのログ）
Requirements for allocation of new commands (i.e., the Code field in the packet header) and new attributes within the standard space are described in [RFC3575], Section 2.1.
（すなわち、コード・パケット・ヘッダ内のフィールド）標準空間内と新しい属性は[RFC3575]に記載されている新しいコマンド、2.1節の割り当てのための要件。
[RFC2865], Section 5.26 defines Vendor-Specific Attributes as follows:
次のように[RFC2865]、セクション5.26は、ベンダー固有の属性を定義します。
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.
この属性は、ベンダーが一般的な使用には適さない独自の拡張属性をサポートすることを可能にするために利用可能です。これは、RADIUSプロトコルの動作に影響してはいけません。
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.
（それは報告されてもよいが）クライアントから送信されたベンダー固有の情報を解釈するために装備されていないサーバはそれを無視しなければなりません。希望ベンダー固有の情報を受信していないクライアントは、彼らがそうする（と彼らがそうしているレポート）かもしれないが劣化モードで、それなしで動作を試みます。
The limitation on changes to the RADIUS protocol effectively prohibits VSAs from changing fundamental aspects of RADIUS operation, such as modifying RADIUS packet sequences or adding new commands. However, the requirement for clients and servers to be able to operate in the absence of VSAs has proven to be less of a constraint since it is still possible for a RADIUS client and server to mutually indicate support for VSAs, after which behavior expectations can be reset.
RADIUSプロトコルの変更の制限を効果的にこのようなRADIUSパケット列を修正したり、新しいコマンドを追加するようRADIUS動作の基本的な側面を、変更からVSAを禁止します。その後の行動の期待をすることができしかし、クライアントとサーバの要件は、それが相互のVSAのサポートを示すために、RADIUSクライアントとサーバのため、まだ可能であるため、制約の少ないことが証明されていたVSAが存在しない状態で動作できるようにするにはリセット。
Therefore, RFC 2865 provides considerable latitude for development of new attributes within the vendor space, while prohibiting development of protocol variants. This flexibility implies that RADIUS attributes can often be developed within the vendor space without loss (and possibly even with gain) in functionality.
プロトコル変異体の開発を禁止しつつ、RFC 2865は、ベンダの空間内に新しい属性を開発するためのかなりの自由度を提供します。この柔軟性は、RADIUSアトリビュートことを意味し、多くの場合、損失することなく、ベンダーのスペース内で開発すること（そしておそらくさえゲインと）機能にすることができます。
As a result, translation of RADIUS attributes developed within the vendor space into the standard space may provide only modest benefits, while accelerating the exhaustion of the standard space. We do not expect that all RADIUS attribute specifications requiring interoperability will be developed within the IETF, and allocated from the standard space. A more scalable approach is to recognize the flexibility of the vendor space, while working toward improvements in the quality and availability of RADIUS attribute specifications, regardless of where they are developed.
標準空間の枯渇を加速しながらその結果、標準の空間に、ベンダーのスペース内で開発RADIUS属性の翻訳は、わずかな利点を提供することができます。私たちは、相互運用性を必要とするすべてのRADIUS属性の仕様は、IETF内で開発、および標準の空間から割り当てされることを期待していません。よりスケーラブルなアプローチは関係なく、それらが開発されている場合の、RADIUS属性の仕様の品質と可用性の改善に向かって仕事をしながら、ベンダースペースの柔軟性を認識することです。
It is therefore NOT RECOMMENDED that specifications intended solely for use by a vendor or SDO be translated into the standard space.
したがって、単にベンダーやSDOが使用するためのものな仕様は、標準的なスペースに翻訳することはお勧めしません。
This section outlines the rationale behind the above recommendations.
このセクションでは、上記の勧告の理論的根拠を概説します。
The RADIUS operational model includes several assumptions:
RADIUS運用モデルは、いくつかの仮定が含まれています。
* The RADIUS protocol is stateless.
* RADIUSプロトコルはステートレスです。
* Provisioning of services is not possible within an Access-Reject or Disconnect-Request.
*サービスのプロビジョニングは、アクセス拒否または外しリクエスト内で可能ではありません。
* There is a distinction between authorization checks and user authentication.
*認証チェックとユーザー認証の区別があります。
* The protocol provides for authentication and integrity protection of packets.
*プロトコルは、パケットの認証と完全性保護を提供します。
* The RADIUS protocol is a Request/Response protocol.
* RADIUSプロトコルは、要求/応答プロトコルです。
* The protocol defines packet length restrictions.
*プロトコルは、パケット長の制限を定義します。
While RADIUS server implementations may keep state, the RADIUS protocol is stateless, although information may be passed from one protocol transaction to another via the State Attribute. As a result, documents that require stateful protocol behavior without use of the State Attribute are inherently incompatible with RADIUS as defined in [RFC2865] and MUST be redesigned. See [RFC5080], Section 2.1.1 for additional discussion surrounding the use of the State Attribute.
RADIUSサーバの実装状態を保つことがありますが情報は州属性を経由して別のプロトコルトランザクションから渡されてもよいが、RADIUSプロトコルは、ステートレスです。その結果、国家の属性を使用せずにステートフルなプロトコルの動作を必要とする文書は、[RFC2865]で定義されているRADIUSと本質的に互換性がなく、再設計されなければなりません。州属性の使用を囲む追加の議論については、セクション2.1.1を[RFC5080]を参照してください。
As noted in [RFC5080], Section 2.6, the intent of an Access-Reject is to deny access to the requested service. As a result, RADIUS does not allow the provisioning of services within an Access-Reject or
[RFC5080]、セクション2.6で述べたように、拒否アクセスの目的は、要求されたサービスへのアクセスを拒否することです。その結果、RADIUSは拒否アクセス内のサービスの提供を許可していませんか
Disconnect-Request. Documents that include provisioning of services within an Access-Reject or Disconnect-Request are inherently incompatible with RADIUS and need to be redesigned.
外し-Requestを。アクセス拒否または外し、リクエスト内のサービスのプロビジョニングを含む文書は、本質的にRADIUSと互換性がないと再設計する必要があります。
[RFC5176], Section 3 notes the following:
[RFC5176]、第3節では、以下の注意事項：
A Disconnect-Request MUST contain only NAS and session identification attributes. If other attributes are included in a Disconnect-Request, implementations MUST send a Disconnect-NAK; an Error-Cause Attribute with value "Unsupported Attribute" MAY be included.
外しリクエストはNASとのセッション識別属性を含まなければなりません。他の属性を外し、要求に含まれている場合、実装は外し-NAKを送らなければなりません。値「サポートされていない属性」とのエラー原因の属性が含まれるかもしれません。
As a result, documents that include provisioning of services within a Disconnect-Request are inherently incompatible with RADIUS and need to be redesigned.
その結果、切り離しリクエスト内のサービスのプロビジョニングを含む文書は、RADIUSと本質的に互換性がないと再設計する必要があります。
As noted in [RFC5080], Section 2.1.1, a RADIUS Access-Request may not contain user authentication attributes or a State Attribute linking the Access-Request to an earlier user authentication. Such an Access-Request, known as an authorization check, provides no assurance that it corresponds to a live user. RADIUS specifications defining attributes containing confidential information (such as Tunnel-Password) should be careful to prohibit such attributes from being returned in response to an authorization check. Also, [RFC5080], Section 2.1.1 notes that authentication mechanisms need to tie a sequence of Access-Request/Access-Challenge packets together into one authentication session. The State Attribute is RECOMMENDED for this purpose.
[RFC5080]、セクション2.1.1で述べたように、RADIUSアクセス - 要求は、ユーザ認証属性以前のユーザ認証にアクセス要求を連結する状態属性を含んでいてもよいです。承認チェックとして知られているこのようなアクセス要求は、それが生きてユーザーに対応することを保証するものではなく。 （例えばトンネルパスワードなど）の機密情報を含む属性を定義RADIUSの仕様は、承認チェックに応答して返されてから、このような属性を禁止するように注意する必要があります。また、[RFC5080]、認証機構はつの認証セッションに一緒にアクセス要求/アクセスチャレンジパケットのシーケンスを結合する必要があることセクション2.1.1ノート。状態属性は、この目的のために推奨されます。
While [RFC2865] did not require authentication and integrity protection of RADIUS Access-Request packets, subsequent authentication mechanism specifications, such as RADIUS/EAP [RFC3579] and Digest Authentication [RFC5090], have mandated authentication and integrity protection for certain RADIUS packets. [RFC5080], Section 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets, including Access-Request packets performing authorization checks. It is expected that specifications for new RADIUS authentication mechanisms will continue this practice.
[RFC2865]はRADIUSアクセス要求パケットの認証と完全性保護を必要としませんでしたが、このようなRADIUS / EAP [RFC3579]とダイジェスト認証[RFC5090]のように、後続の認証メカニズムの仕様は、特定のRADIUSパケットの認証と完全性保護を義務付けています。 [RFC5080]、セクション2.1.1は、この動作は、認証チェックを実行するアクセス要求パケットを含む、すべてのAccess-Requestパケットのために推奨なります。新しいRADIUS認証メカニズムの仕様は、この練習を継続することが予想されます。
The RADIUS protocol as defined in [RFC2865] is a request-response protocol spoken between RADIUS clients and servers. A single RADIUS request packet ([RFC2865], [RFC2866], or [RFC5176]) will solicit in response at most a single response packet, sent to the IP address and port of the RADIUS client that originated the request. Changes to this model are likely to require major revisions to existing implementations, and this practice is NOT RECOMMENDED.
[RFC2865]で定義されるようにRADIUSプロトコルはRADIUSクライアントとサーバ間で話さ要求 - 応答プロトコルです。単一RADIUS要求パケット（[RFC2865]、[RFC2866]、または[RFC5176]）は、要求を発したRADIUSクライアントのIPアドレスとポートに送信されるほとんどの単一の応答パケット、で対応して勧誘します。このモデルへの変更は、既存の実装への主要な改訂を必要とする可能性があり、そしてこのような行為はお勧めしません。
The Length field in the RADIUS packet header is defined in [RFC2865] Section 3. It is noted there that the maximum length of a RADIUS packet is 4096 octets. As a result, attribute designers SHOULD NOT assume that a RADIUS implementation can successfully process RADIUS packets larger than 4096 octets.
RADIUSパケットヘッダの長さフィールドは、RADIUSパケットの最大長は4096個のオクテットであることが注目される[RFC2865]セクション3で定義されています。その結果、設計者は、RADIUSの実装が正常にRADIUSが4096オクテットより大きいパケットを処理できることを仮定するべきではありません属性。
Even when packets are less than 4096 octets, they may be larger than the Path Maximum Transmission Unit (PMTU). Any packet larger than the PMTU will be fragmented, making communications more brittle as firewalls and filtering devices often discard fragments. Transport of fragmented UDP packets appears to be a poorly tested code path on network devices. Some devices appear to be incapable of transporting fragmented UDP packets, making it difficult to deploy RADIUS in a network where those devices are deployed. We RECOMMEND that RADIUS messages be kept as small possible.
パケット未満4096オクテットている場合でも、彼らはパス最大伝送ユニット（PMTU）よりも大きくてもよいです。 PMTUより大きい任意のパケットがファイアウォールやフィルタリングデバイスは、多くの場合、断片を捨てるなどの通信が脆くなって、断片化されます。断片化されたUDPパケットの輸送は、ネットワークデバイス上の悪いテストコードパスであるように思われます。一部のデバイスは、それが難しいこれらのデバイスが展開されているネットワークにRADIUSを展開すること、断片化されたUDPパケットを転送することができないように見えます。私たちは、RADIUSメッセージは小さな可能として保持することをお勧めします。
If a situation is envisaged where it may be necessary to carry authentication, authorization, or accounting data in a packet larger than 4096 octets, then one of the following approaches is RECOMMENDED:
4096オクテットより大きいパケットに認証、許可、またはアカウンティングデータを運ぶために必要があるかもしれないという状況が想定されている場合は、次のいずれかの方法をお勧めします。
1. Utilization of a sequence of packets. For RADIUS authentication, a sequence of Access-Request/Access-Challenge packets would be used. For this to be feasible, attribute designers need to enable inclusion of attributes that can consume considerable space within Access-Challenge packets. To maintain compatibility with existing NASes, either the use of Access-Challenge packets needs to be permissible (as with RADIUS/EAP, defined in [RFC3579]) or support for receipt of an Access-Challenge needs to be indicated by the NAS (as in RADIUS Location [RFC5580]). Also, the specification needs to clearly describe how attribute splitting is to be signaled and how attributes included within the sequence are to be interpreted, without requiring stateful operation. Unfortunately, previous specifications have not always exhibited the required foresight. For example, even though very large filter rules are conceivable, the NAS-Filter-Rule Attribute defined in [RFC4849] is not permitted in an Access-Challenge packet, nor is a mechanism specified to allow a set of NAS-Filter-Rule Attributes to be split across an Access-Request/Access-Challenge sequence.
パケットのシーケンスの1活用。 RADIUS認証では、アクセス要求/アクセスチャレンジパケットのシーケンスが使用されます。これが実現可能であるためには、属性の設計者は、アクセスチャレンジパケットの中にかなりのスペースを消費できる属性を含めることを有効にする必要があります。既存のNASとの互換性を維持する、のいずれかでアクセスチャレンジパケットの使用が許容（[RFC3579]で定義されたRADIUS / EAP、のように）、またはアクセスチャレンジを受信するためのサポートする必要があるためには（NASによって示される必要があるようRADIUS場所で[RFC5580]）。また、仕様は、属性分割をシグナリングする方法と配列内に含まれる属性は、ステートフルな操作を必要とせず、解釈されるべきである方法を明確に記述する必要があります。残念ながら、以前の仕様は、常に必要な先見の明を示していません。非常に大規模なフィルタ規則が考えられるにもかかわらず、例えば、[RFC4849]で定義されたNAS-フィルタルール属性は、アクセスチャレンジパケットに許可されていない、また機構は、NAS-フィルタルール属性のセットを可能にするように指定されていますアクセス要求/アクセスチャレンジシーケンスに分割することにします。
In the case of RADIUS accounting, transporting large amounts
of data would require a sequence of Accounting-Request
packets. This is a non-trivial change to RADIUS, since RADIUS
accounting clients would need to be modified to split the attribute stream across multiple Accounting-Requests, and
billing servers would need to be modified to reassemble and
interpret the attribute stream.
2. Utilization of names rather than values. Where an attribute relates to a policy that could conceivably be pre-provisioned on the NAS, then the name of the pre-provisioned policy can be transmitted in an attribute rather than the policy itself, which could be quite large. An example of this is the Filter-Id Attribute defined in [RFC2865], Section 5.11, which enables a set of pre-provisioned filter rules to be referenced by name.
名前ではなく、値の2活用。属性が考えられるNAS上で事前プロビジョニングされ得るポリシーに関する場合、その後、プレプロビジョニングポリシーの名前は、属性ではなく、非常に大きくなる可能性がポリシー自体に送信することができます。この例は、名前によって参照される事前プロビジョニングフィルタ規則の集合を可能に[RFC2865]で定義されたフィルタID属性、セクション5.11、です。
3. Utilization of Packetization Layer Path MTU Discovery techniques, as specified in [RFC4821]. As a last resort, where the above techniques cannot be made to work, it may be possible to apply the techniques described in [RFC4821] to discover the maximum supported RADIUS packet size on the path between a RADIUS client and a home server. While such an approach can avoid the complexity of utilization of a sequence of packets, dynamic discovery is likely to be time consuming and cannot be guaranteed to work with existing RADIUS implementations. As a result, this technique is not generally applicable.
[RFC4821]で指定されるようにパケット化層のパスMTU発見技術の3活用。上記の技術を動作させることができない最後の手段として、RADIUSクライアントとホームサーバー間のパス上の最大サポートRADIUSパケットサイズを発見するために、[RFC4821]に記載された技術を適用することも可能です。このようなアプローチは、パケットのシーケンスの利用の複雑さを避けることができますが、動的な発見は時間がかかる可能性があると、既存のRADIUS実装で動作することを保証することはできません。その結果、この技術は、一般的に適用されていません。
While [RFC2865], Section 5 defines basic data types, later specifications did not follow this practice. This problem has led implementations to define their own names for data types, resulting in non-standard names for those types.
[RFC2865]は、第5章は、基本データ型を定義しますが、後で仕様は、この練習に従っていませんでした。この問題は、これらのタイプのための非標準名で、その結果、データ型に自分の名前を定義するために実装をリードしてきました。
In addition, the number of vendors and SDOs creating new attributes within the vendor space has grown, and this has led to some divergence in approaches to RADIUS attribute design. For example, vendors and SDOs have evolved the data model to support functions such as new data types along with attribute grouping and attribute fragmentation, with different groups taking different approaches. These approaches are often incompatible, leading to additional complexity in RADIUS implementations.
また、ベンダー空間内の新しい属性を作成するベンダーとのSDOの数が成長しているし、これは、RADIUS属性のデザインへのアプローチでは、いくつかの相違につながっています。例えば、ベンダーとのSDOは、そのような属性がグループ化し、異なるグループが、異なるアプローチをとることで、断片化属性と共に新しいデータ型などの機能をサポートするデータモデルを進化させてきました。これらのアプローチは、RADIUS実装では、追加の複雑さにつながる、しばしば互換性がありません。
In order to avoid repeating old mistakes, this section describes the history of the RADIUS data model and attempts to codify existing practices.
古い過ちを繰り返さないようにするためには、このセクションでは、RADIUSデータモデルの歴史を説明し、既存の慣行を成文化しようとします。
[RFC2865], Section 5 explicitly defines five data types: text, string, address, integer, and time. Both the names and interpretations of the types are given.
テキスト、文字列、アドレス、整数、時間：[RFC2865]は、第5節では、明示的に5つのデータタイプを定義します。どちらのタイプの名前および解釈が与えられています。
Subsequent RADIUS specifications defined attributes by using type names not defined in [RFC2865], without defining the new names as done in [RFC2865]. They did not consistently indicate the format of the value field using the same conventions as [RFC2865]. As a result, the data type is ambiguous in some cases and may not be consistent among different implementations.
その後のRADIUSの仕様は、[RFC2865]で行ったように新しい名前を定義することなく、[RFC2865]で定義されていないタイプの名前を使用して属性を定義しました。彼らは一貫して、[RFC2865]と同じ規則を使用して、値フィールドのフォーマットを示すものではありませんでした。結果として、データタイプがある場合には曖昧であり、異なる実装の間で一貫性がないかもしれません。
It is out of the scope of this document to resolve all potential ambiguities within existing RADIUS specifications. However, in order to prevent future ambiguities, it is RECOMMENDED that future RADIUS attribute specifications explicitly define newly created data types at the beginning of the document and indicate clearly the data type to be used for each attribute.
これは、既存のRADIUS仕様の範囲内でのすべての潜在的なあいまいさを解決するために、このドキュメントの範囲外です。しかし、将来のあいまいさを防ぐために、将来のRADIUS属性の仕様が明示的にドキュメントの先頭に新たに作成されたデータ型を定義し、明確に各属性に使用するデータの種類を示すことが推奨されます。
For example, [RFC3162] utilizes, but does not explicitly define, a type that encapsulates an IPv6 address (Sections 2.1 and 2.4) and another type that encapsulates an IPv6 prefix (Section 2.3). The IPv6 address attributes confusingly are referenced as type "Address" in the document. This is a similar name as the "address" type defined in [RFC2865], which was defined to refer solely to IPv4 addresses.
例えば、[RFC3162]を使用するが、明示的に、IPv6アドレス（セクション2.1および2.4）とIPv6プレフィックス（セクション2.3）をカプセル化する別のタイプのカプセル化タイプを定義していません。 IPv6アドレスは、紛らわしい文書の種類「住所」として参照される属性。これは、IPv4アドレスのみに参照するために定義された[RFC2865]で定義される「アドレス」タイプ、同様の名前です。
While the Framed-Interface-Id Attribute defined in [RFC3162], Section 2.2 included a value field of 8 octets, the data type was not explicitly indicated; therefore, there is controversy over whether the format of the data was intended to be an 8-octet String or whether a special Interface-Id type was intended.
[RFC3162]で定義入れる-インタフェース-ID属性は、セクション2.2は8つのオクテットの値フィールドが含まれているが、データ型は、明示的に示されませんでした。従って、データの形式は8オクテットストリングまたは特別なインタフェースIDタイプが意図したかどうかであることが意図されたかどうか論争があります。
Given that attributes encapsulating an IPv6 address and an IPv6 prefix are already in use, it is RECOMMENDED that RADIUS server implementations include support for these as basic types, in addition to the types defined in [RFC2865]. Where the intent is to represent a specific IPv6 address, an "IPv6 address" type SHOULD be used. Although it is possible to use an "IPv6 Prefix" type with a prefix length of 128 to represent an IPv6 address, this usage is NOT RECOMMENDED. Implementations supporting the Framed-Interface-Id Attribute may select a data type of their choosing (most likely an 8-octet String or a special "Interface Id" data type).
すでに使用されているIPv6アドレスとIPv6プレフィックスをカプセル化する属性のことを考えると、RADIUSサーバの実装は、[RFC2865]で定義された型に加えて、基本的な型としてこれらのサポートを含めることをお勧めします。目的は、特定のIPv6アドレスを表現する場合、の「IPv6アドレス」タイプが使用されるべきです。それはIPv6アドレスを表現するために128のプレフィックス長との「IPv6プレフィックス」タイプを使用することも可能であるが、この使用は推奨されません。額縁・インタフェース-ID属性をサポートする実装は、自分の選んだ（最も可能性が高い8オクテット文字列や特別な「インタフェースID」データ型）のデータタイプを選択することができます。
It is worth noting that since RADIUS only supports unsigned integers of 32 bits, attributes using signed integer data types or unsigned integer types of other sizes will require code changes and SHOULD be avoided.
これは、RADIUSのみ32ビットの符号なし整数をサポートするので、コードの変更を必要とする符号付き整数データ型、または他のサイズの符号なし整数型を使用して、属性、回避されるべきであることは注目に値します。
For [RFC2865] RADIUS VSAs, the length limitation of the String and Text types is 247 octets instead of 253 octets, due to the additional overhead of the Vendor-Specific Attribute.
[RFC2865]のRADIUS VSAのために、文字列とテキストタイプの長さの制限は、ベンダー固有の属性の追加オーバーヘッドに起因247オクテットの代わりに253オクテットです。
[RFC2868] defines an attribute grouping mechanism based on the use of a one-octet tag value. Tunnel attributes that refer to the same tunnel are grouped together by virtue of using the same tag value.
[RFC2868]は1オクテットのタグ値の使用に基づく属性グループ化機構を定義します。同じトンネルを参照するトンネル属性が同じタグ値を用いによって一緒にグループ化されます。
This tagging mechanism has some drawbacks. There are a limited number of unique tags (31). The tags are not well suited for use with arbitrary binary data values because it is not always possible to tell if the first byte after the Length is the tag or the first byte of the untagged value (assuming the tag is optional).
このタギングメカニズムは、いくつかの欠点があります。独自のタグ（31）の数は限られています。長さの後の最初のバイトは、タグまたは（タグがオプションであると仮定して）タグなし値の最初のバイトである場合に指示することは必ずしも可能ではないため、タグは任意のバイナリデータ値との使用に適していません。
Other limitations of the tagging mechanism are that when integer values are tagged, the value portion is reduced to three bytes, meaning only 24-bit numbers can be represented. The tagging mechanism does not offer an ability to create nested groups of attributes. Some RADIUS implementations treat tagged attributes as having the additional data types tagged-string and tagged-integer. These types increase the complexity of implementing and managing RADIUS systems.
タギング機構の他の制限は、整数値がタグ付けされている場合、値部分のみが24ビット数を表すことができることを意味、3バイトに縮小されることです。タギングメカニズムは、属性のネストされたグループを作成する機能を提供していません。いくつかのRADIUS実装はとタグ付き整数の文字列タグ付けされた追加のデータ型を持つものとしてタグ付けされた属性を扱います。これらのタイプは、RADIUSシステムの実装と管理の複雑さを増します。
For these reasons, the tagging scheme described in RFC 2868 is NOT RECOMMENDED for use as a generic grouping mechanism.
これらの理由から、RFC 2868に記述さタギング方式は、一般的なグループ化メカニズムとして使用することは推奨しません。
As described in this section, the creation of complex types can lead to interoperability and deployment issues, so they need to be introduced with care. For example, the RADIUS attribute encoding is summarized in [RFC2865]:
このセクションで説明したように、複合型の作成は、相互運用性と展開の問題につながることができますので、彼らは注意して導入する必要があります。例えば、RADIUS属性のエンコーディングは、[RFC2865]にまとめられています。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
However, some standard attributes pack multiple sub-fields into the "Value" field, resulting in the creation a non-standard, i.e., complex, type. Separating these sub-fields into different attributes, each with its own type and length, would have the following benefits:
しかし、いくつかの標準的な属性は、作成時に非標準、すなわち、複雑な、タイプの結果、「値」フィールドに複数のサブフィールドをパック。異なる属性にこれらのサブフィールドを分離し、独自の種類や長さは、それぞれ、次のような利点があります：
* When manual data entry is required, it is easier for an administrator to enter the data as well-known types rather than as complex structures.
データの手入力が必要とされる*とき、それは同様のタイプとしてではなく、複雑な構造をよく知られているデータを入力するには、管理者のために簡単です。
* It enables additional error checking by leveraging the parsing and validation routines for well-known types.
*これはよく知られている種類の解析と検証ルーチンを活用することで、追加のエラーチェックを可能にします。
* It simplifies implementations by eliminating special-case, attribute-specific parsing.
*これは、特殊なケース、属性固有の構文解析を排除することによって、実装を簡素化します。
One of the fundamental goals of the RADIUS protocol design was to allow RADIUS servers to be configured to support new attributes, without requiring server code changes. RADIUS server implementations typically provide support for basic data types and define attributes in a data dictionary. This architecture enables a new attribute to be supported by the addition of a dictionary entry, without requiring other RADIUS server code changes.
RADIUSプロトコルの設計の基本的な目標の一つは、RADIUSサーバがサーバ・コードの変更を必要とせずに、新しい属性をサポートするように構成することができるようにすることでした。 RADIUSサーバの実装は、通常、基本データ型のサポートを提供し、データ・ディクショナリに属性を定義します。このアーキテクチャは、他のRADIUSサーバのコードの変更を必要とせずに、辞書エントリの追加によりサポートされる新しい属性を可能にします。
Code changes can also be required in policy management systems and in the RADIUS server's receive path. These changes are due to limitations in RADIUS server policy languages, which commonly provide for limited operations (such as comparisons or arithmetic operations) on the existing data types. Many existing RADIUS policy languages typically are not capable of parsing sub-elements or providing more sophisticated matching functionality.
コードの変更は、ポリシー管理システムやRADIUSサーバの受信経路に必要になることができます。これらの変化は、一般的に、既存のデータ型に（このような比較又は算術演算など）を限定された動作を提供するRADIUSサーバポリシー言語の制約に起因しています。多くの既存のRADIUSポリシー言語は、通常のサブ要素を解析したり、より高度なマッチング機能を提供することができません。
On the RADIUS client, code changes are typically required in order to implement a new attribute. The RADIUS client typically has to compose the attribute dynamically when sending. When receiving, a RADIUS client needs to be able to parse the attribute and carry out the requested service. As a result, a detailed understanding of the new attribute is required on clients, and data dictionaries are less useful on clients than on servers.
RADIUSクライアントでは、コードの変更は、一般的に新しい属性を実装するために必要とされます。 RADIUSクライアントは、通常の送信時に動的属性を構成する必要があります。受信すると、RADIUSクライアントは、属性を解析し、要求されたサービスを実行できるようにする必要があります。その結果、新しい属性の詳細な理解は、クライアント上で必要な、およびデータ・ディクショナリは、サーバー上でよりクライアントにはあまり便利ですされています。
Given these limitations, the introduction of new types can require code changes on the RADIUS server, which would be unnecessary if basic data types had been used instead. In addition, if "ad hoc" types are used, attribute-specific parsing is required, which means more complex software to develop and maintain. More complexity can lead to more error-prone implementations, interoperability problems, and even security vulnerabilities. These issues can increase costs to network administrators as well as reduce reliability and introduce deployment barriers.
これらの制限を考えると、新しいタイプの導入は、基本データ型が代わりに使用されていた場合には不要だろうRADIUSサーバ上のコードの変更を必要とすることができます。 「アドホック」タイプが使用されている場合はさらに、属性固有の構文解析を開発し、維持するために、より複雑なソフトウェアを意味し、必要とされます。より多くの複雑さは、多くのエラーが発生しやすいの実装、相互運用性の問題、さらにはセキュリティの脆弱性につながることができます。これらの問題は、ネットワーク管理者にコストを増大させるだけでなく、信頼性が低下し、展開の障壁を導入することができます。
As described in Section 2.1, the introduction of complex data types is discouraged where viable alternatives are available. A potential exception is attributes that inherently require code changes on both the client and server. For example, as described in Appendix B, complex attributes have been used in situations involving authentication and security attributes, which need to be dynamically computed and verified. Supporting this functionality requires code changes on both the RADIUS client and server, regardless of the attribute format. As a result, in most cases, the use of complex attributes to represent these methods is acceptable and does not create additional interoperability or deployment issues.
2.1節で述べたように実行可能な代替が利用可能な場合、複雑なデータ型の導入が推奨されていません。潜在的な例外は、本質的に、クライアントとサーバーの両方でコードの変更を必要とする属性です。付録Bで説明したように、例えば、複合属性は動的に計算して検証する必要が認証およびセキュリティ属性を伴う状況で使用されています。この機能をサポートすることに関係なく、属性形式の、RADIUSクライアントとサーバーの両方で、コードの変更が必要となります。その結果、ほとんどの場合、これらのメソッドを表現するために、複雑な属性の使用が許容され、追加の相互運用性や展開の問題を作成しません。
Another exception to the recommendation against complex types is for types that can be treated as opaque data by the RADIUS server. For example, the EAP-Message Attribute, defined in [RFC3579], Section 3.1, contains a complex data type that is an Extensible Authentication Protocol (EAP) packet. Since these complex types do not need to be parsed by the RADIUS server, the issues arising from server limitations do not arise. Similarly, since attributes of these complex types can be configured on the server using a data type of String, dictionary limitations are also not encountered. Appendix A.1 includes a series of checklists that may be used to analyze a design for RECOMMENDED and NOT RECOMMENDED behavior in relation to complex types.
複合型に対する勧告へのもう一つの例外は、RADIUSサーバによって不透明なデータとして扱うことが可能なタイプです。例えば、[RFC3579]で定義されたEAP-メッセージ属性、セクション3.1は、拡張認証プロトコル（EAP）パケットである複合データ型を含んでいます。これらの複雑なタイプはRADIUSサーバによって解析する必要がないので、サーバーの制限に起因する問題は生じません。これらの複合型の属性は、文字列のデータ型を使用して、サーバー上で設定することができますので、同様に、辞書制限も遭遇していません。付録A.1は推奨されており、複合型に関連して動作推奨しないための設計を分析するために使用することができるチェックリストのシリーズが含まれています。
If the RADIUS Server simply passes the contents of an attribute to some non-RADIUS portion of the network, then the data is opaque to RADIUS and SHOULD be defined to be of type String. A concrete way of judging this requirement is whether or not the attribute definition in the RADIUS document contains delineated fields for sub-parts of the data. If those fields need to be delineated in RADIUS, then the data is not opaque to RADIUS, and it SHOULD be separated into individual RADIUS attributes.
RADIUSサーバは、単にネットワークのいくつかの非RADIUS部に属性の内容をパスした場合、そのデータは、RADIUSに不透明であり、String型であると定義されるべきです。この要件を判断する具体的な方法は、RADIUS文書の属性定義は、データのサブ部品の線引きのフィールドが含まれているかどうかではありません。これらのフィールドは、RADIUSで線引きする必要がある場合、そのデータは、RADIUSに対して不透明ではありません、それは個々のRADIUS属性に分離する必要があります。
An examination of existing RADIUS RFCs discloses a number of complex attributes that have already been defined. Appendix B includes a listing of complex attributes used within [RFC2865], [RFC2868], [RFC2869], [RFC3162], [RFC4818], and [RFC4675]. The discussion of these attributes includes reasons why a complex type is acceptable or suggestions for how the attribute could have been defined to follow the RADIUS data model.
既存のRADIUS RFCの検査は、すでに定義されている複合属性の数を開示しています。付録Bは、[RFC2865]内で使用される複合属性のリストは、[RFC2868]、[RFC2869]、[RFC3162]、[RFC4818]及び[RFC4675]を含みます。これらの属性の議論は、属性がRADIUSデータモデルに従うことが定義されている可能性がどのようにのための複合型が許容される理由や提案を含んでいます。
In other cases, the data in the complex type are described textually in a specification. This is possible because the data types are not sent within the attributes but are a matter for endpoint interpretation. An implementation can define additional data types and use these data types today by matching them to the attribute's textual definition.
他の場合には、複合型のデータは、本明細書にテキストで記述されています。データ型が属性の中に送信されますが、エンドポイントの解釈の問題でされていないので、これは可能です。実装では、追加のデータ型を定義し、属性のテキストの定義にそれらを照合することによって、今日、これらのデータ型を使用することができます。
The usage model for RADIUS VSAs is described in [RFC2865], Section 6.2:
RADIUS VSAのための使用モデルは、[RFC2865]、セクション6.2に記載されています。
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.
RADIUSは、ベンダー固有の拡張子（項目26）ためのメカニズムを定義し、それを使用するだけで何の相互運用性が有用とみなされていないRADIUSの一社のベンダーの実装に特定の機能のために、代わりにグローバル属性タイプの割り当て奨励されるべきであることに留意されたいです。
Nevertheless, many new attributes have been defined in the vendor space in situations where interoperability is not only useful but is required. For example, SDOs outside the IETF (such as the IEEE 802 and the 3rd Generation Partnership Project (3GPP)) have been assigned Vendor-Ids, enabling them to define their own VSA encoding and assign Vendor types within their own vendor space, as defined by their unique Vendor-Id.
それにもかかわらず、多くの新しい属性は、相互運用性だけでなく、便利ですが、必要とされる状況では、ベンダーの空間で定義されています。例えば、（例えば、IEEE 802および第3世代パートナーシッププロジェクト（3GPP）など）IETF外部のSDOは、定義されたように、独自のVSAのエンコーディングを定義し、独自のベンダー空間内のベンダータイプを割り当てるためにそれらを可能にする、のベンダーIDが割り当てられています。独自のベンダーIDによります。
The use of VSAs by SDOs outside the IETF has gained in popularity for several reasons:
IETF外のSDOによってVSAのの使用はいくつかの理由で人気を博しています。
Efficiency As with SNMP, which defines an "Enterprise" Object Identifier (OID) space suitable for use by vendors as well as other SDOs, the definition of Vendor-Specific Attributes has become a common occurrence as part of standards activity outside the IETF. For reasons of efficiency, it is easiest if the RADIUS attributes required to manage a standard are developed within the same SDO that develops the standard itself. As noted in "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few vendors are willing to simultaneously fund individuals to participate within an SDO to complete a standard as well as to participate in the IETF in order to complete the associated RADIUS attributes specification.
「エンタープライズ」オブジェクト識別子（OID）ベンダーによる使用に適した空間ならびに他のSDOを定義するSNMPと同様に、効率は、ベンダー固有の属性の定義は、IETF規格外活動の一環として、一般的出現となっています。標準の管理に必要なRADIUS属性が標準自体を開発し、同じSDO内で開発されている場合は、効率の理由から、それが最も簡単です。 [RFC4663]「IEEE 802.1 WGにIETFブリッジMIB WGからMIB作業を転送する」で述べたように、今日、いくつかのベンダーは同時に標準を完了するだけでなく、するために、IETFへの参加をSDO内参加する個人に資金を供給して喜んでいます関連するRADIUS属性の指定を完了します。
Attribute scarcity The standard space is limited to 255 unique attributes. Of these, only about half remain available for allocation. In the vendor space, the number of attributes available is a function of the encoding of the attribute (the size of the Vendor type field).
希少属性標準スペースは255ユニークな属性に制限されています。これらのうち、約半分のみが割り当て可能なまま。ベンダー空間において、利用可能な属性の数は、属性（ベンダー・タイプ・フィールドのサイズ）の符号化の関数です。
Vendors and SDOs are reminded that the standard space and the enumerated value space for enumerated attributes are reserved for allocation through work published via the IETF, as noted in [RFC3575], Section 2.1. In the past, some vendors and SDOs have assigned vendor-specific meaning to "unused" values from the standard space. This process results in interoperability issues and is counterproductive. Similarly, the vendor-specific enumeration practice discussed in [RFC2882], Section 2.2.1 is NOT RECOMMENDED.
[RFC3575]に記載されているように、ベンダーとのSDOは、IETFを介して公開された標準空間と列挙属性の列挙値の空間が作業を通じて割り当てのために予約されていることを第2.1節を思い出しています。過去には、いくつかのベンダーとのSDOは、標準的な空間から「未使用」の値にベンダー固有の意味が割り当てられています。このプロセスは、相互運用性の問題が生じ、逆効果です。 [RFC2882]で説明した同様に、ベンダー固有の列挙実際、セクション2.2.1は推奨されません。
If it is not possible to follow the IETF process, vendors and SDOs SHOULD self-allocate an attribute, which MUST be in their own vendor space as defined by their unique Vendor-Id, as discussed in Sections 3.3.2 and 3.3.3.
それはIETFプロセスに従うことができない場合は、ベンダーとのSDOは、セクション3.3.2と3.3.3で説明したように、独自のベンダーIDによって定義されるように、独自のベンダー空間でなければならない（MUST）属性を、自己割り当てる必要があります。
The design and specification of VSAs for multi-vendor usage SHOULD be undertaken with the same level of care as standard RADIUS attributes. Specifically, the provisions of this document that apply to standard RADIUS attributes also apply to VSAs for multi-vendor usage.
マルチベンダー使用のためのVSAの設計及び仕様は、標準RADIUS属性としてケアの同じレベルで行われるべきです。具体的には、標準のRADIUSには適用され、この文書の規定は、マルチベンダーの使用のためのVSAに適用される属性。
As noted in [RFC3575], Section 2.1, vendors are encouraged to utilize VSAs to define 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".
[RFC3575]、セクション2.1で述べたように、ベンダーだけ何の相互運用性が有用とみなされていないRADIUSの一社のベンダーの実装に固有の」関数を定義するためにVSAを使用することが奨励される。のみRADIUSのベンダの実装に固有の機能のための使用その代わりに、グローバル属性タイプ」の配分を奨励されるべきです。
The recommendation for vendors to allocate attributes from a vendor space rather than via the IETF process is a recognition that vendors desire to assert change control over their own RADIUS specifications. This change control can be obtained by requesting a PEN from the Internet Assigned Number Authority (IANA) for use as a Vendor-Id within a Vendor-Specific Attribute. The vendor can then allocate attributes within the vendor space defined by that Vendor-Id at their sole discretion. Similarly, the use of data types (complex or otherwise) within that vendor space is solely under the discretion of the vendor.
ベンダー空間からではなく、IETFプロセスを経て、属性を割り当てるためのベンダーのための勧告は、独自のRADIUSの仕様上の変更管理を主張したいベンダーの認識です。この変更制御は、ベンダー固有の属性内のベンダーIDとして使用するための番号機関（IANA）が割り当てられ、インターネットからPENを要求することによって得ることができます。ベンダーは、独自の裁量でそのベンダーIDによって定義されたベンダー・スペース内の属性を割り当てることができます。同様に、そのベンダー・スペース内のデータ型（複合体またはその他）の使用は、単にベンダーの裁量下にあります。
Given the expanded utilization of RADIUS, it has become apparent that requiring SDOs to accomplish all their RADIUS work within the IETF is inherently inefficient and unscalable. It is therefore RECOMMENDED that SDO RADIUS Attribute specifications allocate attributes from the vendor space rather than request an allocation from the RADIUS standard space for attributes matching any of the following criteria:
RADIUSの利用拡大を考えると、それはIETFは、本質的に非効率的かつスケーラブルである内のSDOを必要とするすべてのRADIUSの仕事を達成することが明らかになりました。 SDO RADIUS属性仕様はなく要求よりベンダー空間から次の基準のいずれかに一致する属性のRADIUS標準空間から割り当てを属性を割り当てることが推奨されます。
* Attributes relying on data types not defined within RADIUS
*データの種類に依存する属性はRADIUS内で定義されていません
* Attributes intended primarily for use within an SDO
SDOの中に主に使用するためのもの*属性
* Attributes intended primarily for use within a group of SDOs
SDOののグループ内で主に使用するためのもの*属性
Any new RADIUS attributes or values intended for interoperable use across a broad spectrum of the Internet community SHOULD follow the allocation process defined in [RFC3575].
すべての新しいRADIUS属性またはインターネットコミュニティの幅広い全体で相互運用性の使用を意図した値は、[RFC3575]で定義された割り当てプロセスに従ってください。
The recommendation for SDOs to allocate attributes from a vendor space rather than via the IETF process is a recognition that SDOs desire to assert change control over their own RADIUS specifications. This change control can be obtained by requesting a PEN from the Internet Assigned Number Authority (IANA) for use as a Vendor-Id within a Vendor-Specific Attribute. The SDO can then allocate attributes within the vendor space defined by that Vendor-Id at their sole discretion. Similarly, the use of data types (complex or otherwise) within that vendor space is solely under the discretion of the SDO.
SDOのは、ベンダーの空間からではなく、IETFプロセスを経て、属性を割り当てるための推奨は、SDOのが自分のRADIUSの仕様上の変更管理を主張することを望むという認識です。この変更制御は、ベンダー固有の属性内のベンダーIDとして使用するための番号機関（IANA）が割り当てられ、インターネットからPENを要求することによって得ることができます。 SDOは、独自の裁量でそのベンダーIDによって定義されたベンダー・スペース内の属性を割り当てることができます。同様に、そのベンダー・スペース内のデータ型（複合体またはその他）の使用は、単にSDOの裁量下にあります。
A polymorphic attribute is one whose format or meaning is dynamic. For example, rather than using a fixed data format, an attribute's format might change based on the contents of another attribute. Or, the meaning of an attribute may depend on earlier packets in a sequence.
多型の属性は、その形式や意味、動的なものです。例えば、むしろ固定されたデータ・フォーマットを使用するよりも、属性の形式は、別の属性の内容に基づいて変更される場合があります。または、属性の意味は、シーケンス内の以前のパケットに依存してもよいです。
RADIUS server dictionary entries are typically static, enabling the user to enter the contents of an attribute without support for changing the format based on dynamic conditions. However, this limitation on static types does not prevent implementations from implementing policies that return different attributes based on the contents of received attributes; this is a common feature of existing RADIUS implementations.
RADIUSサーバ辞書エントリは、動的な条件に基づいて、フォーマットを変更するためのサポートなし属性の内容を入力することをユーザに可能にする、一般的に静的です。しかし、静的タイプのこの制限は、受信した属性の内容に基づいて、異なる属性を返すポリシーを実装から実装を妨げません。これは、既存のRADIUS実装の共通の特徴です。
In general, polymorphism is NOT RECOMMENDED. Polymorphism rarely enables capabilities that would not be available through use of multiple attributes. Polymorphism requires code changes in the RADIUS server in situations where attributes with fixed formats would not require such changes. Thus, polymorphism increases complexity while decreasing generality, without delivering any corresponding benefits.
一般的に、多型が推奨されていません。多型はめったに複数の属性を使用して利用できないでしょうな機能を可能にしていません。多型は、固定フォーマットで属性は、このような変更を必要としない状況で、RADIUSサーバでのコードの変更が必要となります。一般性を減少しつつ、多型は、任意の対応する利点を提供することなく、複雑さを増大させます。
Note that changing an attribute's format dynamically is not the same thing as using a fixed format and computing the attribute itself dynamically. RADIUS authentication attributes, such as User-Password, EAP-Message, etc., while being computed dynamically, use a fixed format.
動的属性のフォーマットを変更すると、固定形式を使用して、動的に属性自体の計算と同じものではないことに注意してください。そのようなユーザパスワード、EAP-メッセージ、等のRADIUS認証属性は、動的に計算された状態では、固定フォーマットを使用。
This document has no action items for IANA. However, it does provide guidelines for Expert Reviewers appointed as described in [RFC3575].
この文書は、IANAのためのアクション項目がありません。 [RFC3575]で説明したようにしかし、それは専門家のレビューのためのガイドラインを提供してい任命しました。
This specification provides guidelines for the design of RADIUS attributes used in authentication, authorization, and accounting. Threats and security issues for this application are described in [RFC3579] and [RFC3580]; security issues encountered in roaming are described in [RFC2607].
この仕様は、認証、許可、アカウンティングに使用されるRADIUS属性の設計のためのガイドラインを提供します。このアプリケーションの脅威とセキュリティ問題は[RFC3579]及び[RFC3580]に記載されています。ローミング中に遭遇したセキュリティ問題は[RFC2607]で説明されています。
Obfuscation of RADIUS attributes on a per-attribute basis is necessary in some cases. The current standard mechanism for this is described in [RFC2865], Section 5.2 (for obscuring User-Password values) and is based on the MD5 algorithm specified in [RFC1321]. The MD5 and SHA-1 algorithms have recently become a focus of scrutiny and concern in security circles, and as a result, the use of these algorithms in new attributes is NOT RECOMMENDED. In addition, previous documents referred to this method as generating "encrypted" data. This terminology is no longer accepted within the cryptographic community.
RADIUSの難読化ごとの属性毎に属性をいくつかのケースで必要です。このため、現在の標準的なメカニズムは、（ユーザパスワード値を不明瞭にするための）セクション5.2、[RFC2865]に記載されており、[RFC1321]で指定されたMD5アルゴリズムに基づいています。 MD5とSHA-1アルゴリズムは、最近のセキュリティ界の精査と関心の焦点となっており、結果として、新しい属性でこれらのアルゴリズムの使用は推奨されません。また、以前の文書は、「暗号化」データを生成するものとして、この方法に言及しました。この用語は、もはや暗号コミュニティ内で受け入れられません。
Where new RADIUS attributes use cryptographic algorithms, algorithm negotiation SHOULD be supported. Specification of a mandatory-to-implement algorithm is REQUIRED, and it is RECOMMENDED that the mandatory-to-implement algorithm be certifiable under FIPS 140 [FIPS].
新しいRADIUS属性が暗号化アルゴリズムを使用する場合は、アルゴリズムのネゴシエーションがサポートされる必要があります。 [FIPS]強制的に実装アルゴリズムの仕様が必要であり、強制的に実装アルゴリズムは、FIPS 140の下に認定することが推奨されます。
Where new RADIUS attributes encapsulate complex data types, or transport opaque data, the security considerations discussed in Section 5.1 SHOULD be addressed.
新しいRADIUS属性が複雑なデータ型、または輸送不透明なデータをカプセル化する場合は、セクション5.1で説明したセキュリティの考慮事項が対処する必要があります。
Message authentication in RADIUS is provided largely via the Message-Authenticator attribute. See Section 3.2 of [RFC3579] and also Section 2.2.2 of [RFC5080], which say that client implementations SHOULD include a Message-Authenticator Attribute in every Access-Request.
RADIUSメッセージ認証は、主にMessage-Authenticatorアトリビュートを介して提供されます。クライアントの実装は、すべてのアクセス要求でMessage-Authenticatorアトリビュートを含めるべきであると言う[RFC3579]の3.2節とも[RFC5080]のセクション2.2.2を参照してください。
In general, the security of the RADIUS protocol is poor. Robust deployments SHOULD support a secure communications protocol such as IPsec. See Section 4 of [RFC3579] and Section 5 of [RFC3580] for a more in-depth explanation of these issues.
一般的には、RADIUSプロトコルのセキュリティが貧弱です。堅牢な展開では、IPsecなどの安全な通信プロトコルをサポートする必要があります。これらの問題のより詳細な説明については、[RFC3579]と[RFC3580]のセクション5の第4節を参照してください。
Implementations not following the suggestions outlined in this document may be subject to problems such as ambiguous protocol decoding, packet loss leading to loss of billing information, and denial-of-service attacks.
実装は、そのようなあいまいなプロトコルデコード、課金情報の損失をもたらすパケット損失、およびサービス拒否攻撃などの問題の対象となることがあり、この文書で概説提案に従っていません。
The introduction of complex data types brings the potential for the introduction of new security vulnerabilities. Experience shows that the common data types have few security vulnerabilities, or else that all known issues have been found and fixed. New data types require new code, which may introduce new bugs and therefore new attack vectors.
複雑なデータ型の導入は、新しいセキュリティの脆弱性の導入の可能性をもたらします。経験は、一般的なデータ型は、すべての既知の問題が発見され、修正されたことを他のいくつかのセキュリティ上の脆弱性、またはを持っていることを示しています。新しいデータ型は、新しいバグ、したがって、新しい攻撃ベクトルを導入することができる新しいコードを、必要としています。
Some systems permit complex attributes to be defined via a method that is more capable than traditional RADIUS dictionaries. These systems can reduce the security threat of new types significantly, but they do not remove it entirely.
一部のシステムでは、伝統的なRADIUS辞書よりも可能である方法で定義される複合属性を許します。これらのシステムは、かなり新しいタイプのセキュリティ上の脅威を減らすことができますが、彼らはそれを完全に削除しないでください。
RADIUS servers are highly valued targets, as they control network access and interact with databases that store usernames and passwords. An extreme outcome of a vulnerability due to a new, complex type would be that an attacker is capable of taking complete control over the RADIUS server.
彼らは、ネットワークアクセスを制御し、ユーザ名とパスワードを保存するデータベースと対話としてRADIUSサーバは、高く評価対象です。新しい、複合型に対する脆弱性の極端な結果は、攻撃者がRADIUSサーバを完全に制御することが可能であるということでしょう。
The use of attributes representing opaque data does not reduce this threat. The threat merely moves from the RADIUS server to the system that consumes that opaque data. The threat is particularly severe when the opaque data originates from the user and is not validated by the NAS. In those cases, the RADIUS server is potentially exposed to attack by malware residing on an unauthenticated host.
不透明なデータを表す属性の使用は、この脅威を減らすことはありません。脅威は単にその不透明なデータを消費システムにRADIUSサーバから移動します。不透明なデータがユーザーから発信され、NASによって検証されていない場合の脅威は特に深刻です。これらの例では、RADIUSサーバは、潜在的に認証されていないホスト上に存在するマルウェアによる攻撃にさらされています。
Any system consuming opaque data that originates from a RADIUS system SHOULD be properly isolated from that RADIUS system and SHOULD run with minimal privileges. Any potential vulnerabilities in the non-RADIUS system will then have minimal impact on the security of the system as a whole.
RADIUSシステムから発信された不透明なデータを消費する任意のシステムは、そのRADIUSシステムから適切に分離する必要があり、最小限の権限で実行する必要があります。非RADIUSシステム内の任意の潜在的な脆弱性は、システム全体のセキュリティへの影響は最小限に抑えています。
[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月。
[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）でリモート認証ダイヤル"。
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
[RFC3575] Aboba、B.、 "RADIUSのためのIANAの考慮事項（ユーザサービスにおけるリモート認証ダイヤル）"、RFC 3575、2003年7月。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.
、STD 16、RFC 1155、1990年5月、 "TCP / IPベースのインターネットの管理情報の構造と識別" [RFC1155]ローズ、M.、およびK. McCloghrie、。
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", RFC 1157, May 1990.
[RFC1157]ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン、 "簡易ネットワーク管理プロトコル（SNMP）"、RFC 1157、1990年5月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548]ソーン、G.、 "マイクロソフトのベンダー固有のRADIUSアトリビュート"、RFC 2548、1999年3月。
[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月。
[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月。
[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月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B.およびP.カルフーン、 "RADIUS（ユーザサービスにおけるリモート認証ダイヤル）拡張認証プロトコル（EAP）のサポート"、RFC 3579、2003年9月。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3580] Congdon氏、P.、Aboba、B.、スミス、A.、ゾルン、G.、およびJ.レーゼ、 "IEEE 802.1Xのリモート認証ダイヤルインユーザーサービス（RADIUS）使用上のガイドライン"、RFC 3580、2003年9月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.
[RFC4181]聞いた、C.、エド。、 "MIBドキュメントの著者と査読のためのガイドライン"、BCP 111、RFC 4181、2005年9月。
[RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG", RFC 4663, September 2006.
[RFC4663]ハリントン、D.、RFC 4663、2006年9月 "IEEE 802.1 WGにIETFブリッジMIB WGからMIB作業を転送します"。
[RFC4675] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Attributes for Virtual LAN and Priority Support", RFC 4675, September 2006.
[RFC4675] Congdon氏、P.、サンチェス、M.、およびB. Aboba、 "RADIUSは、仮想LANとプライオリティサポートのための属性"、RFC 4675、2006年9月。
[RFC4679] Mammoliti, V., Zorn, G., Arberg, P., and R. Rennison, "DSL Forum Vendor-Specific RADIUS Attributes", RFC 4679, September 2006.
[RFC4679] Mammoliti、V.、ツォルン、G.、アーベルク、P.、およびR. Rennison、 "DSLフォーラムベンダー固有のRADIUSアトリビュート"、RFC 4679、2006年9月。
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007.
[RFC4818] Salowey、J.とR. Droms、 "RADIUS委任-のIPv6-prefix属性"、RFC 4818、2007年4月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]マシス、M.とJ. Heffner、 "パケット化レイヤのパスMTUディスカバリ"、RFC 4821、2007年3月。
[RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter Rule Attribute", RFC 4849, April 2007.
[RFC4849] Congdon氏、P.、サンチェス、M.、およびB. Aboba、 "RADIUSのフィルタルール属性"、RFC 4849、2007年4月。
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
[RFC5080]ネルソン、D.とA. DeKok、RFC 5080、2007年12月 "ユーザーサービス（RADIUS）の実装の問題と推奨修正に共通のリモート認証ダイヤル"。
[RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, "RADIUS Extension for Digest Authentication", RFC 5090, February 2008.
[RFC5090] Sterman、B.、Sadolevsky、D.、シュワルツ、D.、ウィリアムズ、D.、およびW.ベック、 "ダイジェスト認証のためのRADIUS拡張"、RFC 5090、2008年2月。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
、RFC 5176、2008年1月[RFC5176]千葉、M.、Dommety、G.、エクランド、M.、ミトン、D.、およびB. Aboba、 "ユーザーサービス（RADIUS）でリモート認証ダイヤルへのダイナミックな承認拡張機能"。
[DOCTORS] AAA Doctors Mailing List, www.ietf.org/mail-archive/web/aaa-doctors.
メーリングリスト[DOCTORS] AAA医師、www.ietf.org/mail-archive/web/aaa-doctors。
[FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic Modules", http://csrc.nist.gov/publications/PubsFIPS.html.
[FIPS]は140-3（DRAFT）、 "暗号モジュールのセキュリティ要件"、http://csrc.nist.gov/publications/PubsFIPS.htmlをFIPS。
[IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q-2003, January 2003.
[IEEE-802.1Q]ローカルおよびメトロポリタンエリアネットワークのIEEE標準：2003年1月、仮想ブリッジローカルエリアネットワーク、P802.1Q-2003用標準案。
[RFC5580] Tschofenig, H., Ed., Adrangi, F., Jones, M., Lior, A., and B. Aboba, "Carrying Location Objects in RADIUS and Diameter", RFC 5580, August 2009.
[RFC5580] Tschofenig、H.編、Adrangi、F.、ジョーンズ、M.、LIOR、A.およびB. Aboba、 "RADIUS直径Locationオブジェクトを運ぶ"、RFC 5580、2009年8月。
[AAA-SIP] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, "RADIUS Extension for Digest Authentication", Work in Progress, November 2004.
[AAA-SIP] Sterman、B.、Sadolevsky、D.、シュワルツ、D.、ウィリアムズ、D.、およびW.ベック、 "ダイジェスト認証のためのRADIUS拡張"、進歩、2004年11月に作業。
Appendix A. Design Guidelines Checklist
付録A.設計ガイドラインのチェックリスト
The following text provides guidelines for the design of attributes used by the RADIUS protocol. Specifications that follow these guidelines are expected to achieve maximum interoperability with minimal changes to existing systems.
次のテキストは、RADIUSプロトコルによって使用される属性を設計するためのガイドラインを提供します。これらのガイドラインに従ってください仕様は、既存のシステムへの最小限の変更で最大の相互運用性を達成することが期待されています。
A.1. Types Matching the RADIUS Data Model
A.1。 RADIUSデータモデルマッチングタイプ
A.1.1. Transport of Basic Data Types
A.1.1。基本データ型の交通
Does the data fit within the basic data types described in Section 2.1? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS attribute or in a [RFC2865] format RADIUS VSA that uses one of the existing RADIUS data types.
データは2.1節で説明した基本的なデータ型に収まるのか？そうである場合、それは[RFC2865]形式のRADIUS属性で、または既存のRADIUSデータ型の1つを使用する[RFC2865]形式RADIUS VSAの中にカプセル化されるべきです。
A.1.2. Transport of Authentication and Security Data
A.1.2。認証とセキュリティデータの交通
Does the data provide authentication and/or security capabilities for the RADIUS protocol as outlined below? If so, use of a complex data type is acceptable under the following circumstances:
下記のとおりデータは、RADIUSプロトコルの認証および/またはセキュリティ機能を提供していますか？もしそうであれば、複合データ型の使用は、以下の状況下で許容されます。
* Complex data types that carry authentication methods that RADIUS servers are expected to parse and verify as part of an authentication process.
RADIUSサーバが認証プロセスの一部として解析し、検証することが期待されている認証方式を運ぶ*複合データ型。
* Complex data types that carry security information intended to increase the security of the RADIUS protocol itself.
RADIUSプロトコル自体のセキュリティを向上させることを意図したセキュリティ情報を運ぶ*複合データ型。
Any data type carrying authentication and/or security data that is not meant to be parsed by a RADIUS server is an "opaque data type", as defined in Section A.1.3.
セクションA.1.3で定義されているRADIUSサーバによって解析されることを意図されていない認証および/またはセキュリティデータを搬送する任意のデータ型は、「不透明なデータ型」です。
A.1.3. Opaque Data Types
A.1.3。不透明なデータ型
Does the attribute encapsulate an existing data structure defined outside of the RADIUS specifications? Can the attribute be treated as opaque data by RADIUS servers (including proxies)? If both questions can be answered affirmatively, a complex structure MAY be used in a RADIUS specification.
属性は、RADIUS仕様の外で定義された既存のデータ構造をカプセル化していますか？属性は（プロキシを含む）RADIUSサーバが不透明なデータとして扱うことはできますか？両方の質問が肯定的に答えることができるならば、複雑な構造は、RADIUS仕様で使用されるかもしれません。
The specification of the attribute SHOULD define the encapsulating attribute to be of type String. The specification SHOULD refer to an external document defining the structure. The specification SHOULD NOT define or describe the structure, for reasons discussed in Section 3.2.3.
属性の指定はString型であることをカプセル化する属性を定義する必要があります。仕様は以下の構造を定義する外部文書を参照すべきです。仕様は、セクション3.2.3で説明した理由により、構造を定義するかについて説明すべきではありません。
A.1.4. Pre-Existing Data Types
A.1.4。既存のデータ・タイプ
There is a trade-off in design between reusing existing formats for historical compatibility or choosing new formats for a "better" design. This trade-off does not always require the "better" design to be used. As a result, pre-existing complex data types described in Appendix B MAY be used.
歴史的な互換性のために既存のフォーマットを再利用するか、「より良い」設計のための新しいフォーマットを選択する間の設計におけるトレードオフがあります。このトレードオフは、常に使用される「より良い」のデザインを必要としません。結果として、付録Bに記載の既存の複合データ型を使用することができます。
A.2. Improper Data Types
A.2。不適切なデータ型
This section suggests alternatives to data types that do not fall within the "basic data type" definition. Section A.2.1 describes simple data types, which should be replaced by basic data types. Section A.2.2 describes more complex data types, which should be replaced by multiple attributes using the basic data types.
このセクションでは、「基本データ型」の定義に該当しないデータ型への代替を示唆しています。 A.2.1項は、基本データ型に置き換える必要があり、単純なデータ型について説明します。 A.2.2項は、基本データ型を使用して複数の属性に置き換える必要があり、より複雑なデータ型について説明します。
A.2.1. Simple Data Types
A.2.1。単純データ型
Does the attribute use any of the following data types? If so, the data type SHOULD be replaced with the suggested alternatives, or it SHOULD NOT be used at all.
属性には、次のデータ型のいずれかを使用していますか？その場合は、データ型が修正候補に置き換える必要があり、またはそれは全く使用されるべきではありません。
* Signed integers of any size. SHOULD NOT be used. SHOULD be replaced with one or more unsigned integer attributes. The definition of the attribute can contain information that would otherwise go into the sign value of the integer.
*任意のサイズの符号付き整数。使用されるべきではありません。一つ以上の符号なし整数属性に置き換えてください。属性の定義は、そうでない場合は、整数の符号値に行くだろうな情報を含めることができます。
* 8-bit unsigned integers. SHOULD be replaced with 32-bit unsigned integer. There is insufficient justification to save three bytes.
* 8ビットの符号なし整数。 32ビット符号なし整数に置き換えてください。 3つのバイトを保存するのに十分な正当性があります。
* 16-bit unsigned integers. SHOULD be replaced with 32-bit unsigned integer. There is insufficient justification to save two bytes.
* 16ビット符号なし整数。 32ビット符号なし整数に置き換えてください。 2つのバイトを保存するのに十分な正当性があります。
* Unsigned integers of size other than 32 bits. SHOULD be replaced by an unsigned integer of 32 bits. There is insufficient justification to define a new size of integer.
* 32ビット以外のサイズの符号なし整数。 32ビットの符号なし整数に置き換えてください。整数の新しいサイズを定義するのに十分な正当性があります。
* Integers of any size in non-network byte order. SHOULD be replaced by unsigned integer of 32 bits in network. There is no reason to transport integers in any format other than network byte order.
*非ネットワークバイトオーダーで任意のサイズの整数。ネットワーク内の32ビットの符号なし整数に置き換えてください。ネットワークバイトオーダー以外の任意の形式で整数を輸送する理由はありません。
* Multi-field text strings. Each field SHOULD be encapsulated in a separate attribute.
*マルチフィールドのテキスト文字列。各フィールドには、別の属性にカプセル化されるべきである（SHOULD）。
* Polymorphic attributes. Multiple attributes, each with a static data type, SHOULD be defined instead.
*ポリモーフィックな属性。複数の属性、静的データタイプのそれぞれは、代わりに定義されるべきです。
* Nested attribute-value pairs (AVPs). Attributes should be defined in a flat typespace.
*ネストされた属性値ペア（AVPの）。属性は、フラットtypespaceで定義する必要があります。
A.2.2. More Complex Data Types
A.2.2。より複雑なデータ・タイプ
Does the attribute:
属性が行われます。
* define a complex data type not described in Appendix B?
*付録Bに記述されていない複雑なデータ型を定義しますか？
* that a RADIUS server and/or client is expected to parse, validate, or create the contents of via a dynamic computation (i.e., a type that cannot be treated as opaque data (Section A.1.3))?
* RADIUSサーバ及び/又はクライアントは、構文解析、検証、または動的計算（すなわち、不透明なデータとして扱うことができないタイプ（セクションA.1.3））を介してのコンテンツを作成することが期待されていること？
* involve functionality that could be implemented without code changes on both the client and server (i.e., a type that doesn't require dynamic computation and verification, such as those performed for authentication or security attributes)?
*クライアントとサーバの両方でコードを変更することなく実現することができる官能基を含む（すなわち、例えば認証またはセキュリティ属性に対して実行されるものとして動的計算および検証を必要としないタイプ）？
If so, this data type SHOULD be replaced with simpler types, as discussed in Appendix A.2.1. See also Section 2.1 for a discussion of why complex types are problematic.
その場合は、付録A.2.1で説明したように、このデータ型は、シンプルなタイプに置き換える必要があります。複雑なタイプが問題である理由の議論のためにも、2.1節を参照してください。
A.3. Vendor-Specific Formats
A.3。ベンダー固有のフォーマット
Does the specification contain Vendor-Specific Attributes that match any of the following criteria? If so, the VSA encoding should be replaced with the [RFC2865], Section 5.26 encoding or should not be used at all.
仕様は以下の基準のいずれかに一致するベンダー固有の属性が含まれていますか？もしそうであれば、VSAの符号化は、セクション5.26符号化、[RFC2865]に置き換えなければならないか、または全く使用すべきではありません。
* Vendor types of more than 8 bits. SHOULD NOT be used. Vendor types of 8 bits SHOULD be used instead.
* 8ビット以上のベンダータイプ。使用されるべきではありません。 8ビットのベンダータイプが代わりに使用されるべきです。
* Vendor lengths of less than 8 bits (i.e., zero bits). SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used instead.
*未満の8ビット（すなわち、ゼロビット）のベンダーの長さ。使用されるべきではありません。 8ビットのベンダー長が代わりに使用されるべきです。
* Vendor lengths of more than 8 bits. SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used instead.
* 8ビット以上のベンダーの長さ。使用されるべきではありません。 8ビットのベンダー長が代わりに使用されるべきです。
* Vendor-specific contents that are not in Type-Length-Value format. SHOULD NOT be used. Vendor-Specific Attributes SHOULD be in Type-Length-Value format.
*なType-Length-値の形式になっていないベンダー固有の内容。使用されるべきではありません。ベンダー固有の属性は、Type-長さと値の形式である必要があります。
In general, Vendor-Specific Attributes SHOULD follow the encoding suggested in Section 5.26 of [RFC2865]. Vendor extensions to non-standard encodings are NOT RECOMMENDED as they can negatively affect interoperability.
一般に、ベンダー固有の属性は、[RFC2865]のセクション5.26で提案符号化に従うべきです。彼らは負の相互運用性に影響を与えることができるように、非標準のエンコーディングにベンダー拡張機能は推奨されません。
A.4. Changes to the RADIUS Operational Model
A.4。 RADIUS運用モデルへの変更
Does the specification change the RADIUS operation model as outlined in the list below? If so, then another method of achieving the design objectives SHOULD be used. Potential problem areas include the following:
以下のリストに概説されているよう仕様は、RADIUSの動作モデルを変更していますか？もしそうなら、設計目標を達成するための別の方法を使用する必要があります。潜在的な問題領域には次のものがあります。
* Defining new commands in RADIUS using attributes. The addition of new commands to RADIUS MUST be handled via allocation of a new Code and not by the use of an attribute. This restriction includes new commands created by overloading the Service-Type Attribute to define new values that modify the functionality of Access-Request packets.
*属性を使用してRADIUSに新しいコマンドを定義します。 RADIUSに新しいコマンドを追加するには、新しいコードの割り当てを経由していない属性を使用して処理する必要があります。この制限は、アクセス要求パケットの機能を変更、新しい値を定義するにはservice-type属性をオーバーロードによって作成された新しいコマンドが含まれています。
* Using RADIUS as a transport protocol for data unrelated to authentication, authorization, or accounting. Using RADIUS to transport authentication methods such as EAP is explicitly permitted, even if those methods require the transport of relatively large amounts of data. Transport of opaque data relating to AAA is also permitted, as discussed in Section 3.2.3. However, if the specification does not relate to AAA, then RADIUS SHOULD NOT be used.
*認証、許可、またはアカウンティングとは無関係のデータのトランスポートプロトコルとしてRADIUSを使用します。このようEAPなどの認証方法を輸送するためにRADIUSを使用すると、明示的にこれらのメソッドは、比較的大量のデータの転送を要求した場合でも、許可されています。セクション3.2.3で説明したようにAAAに関連する不透明なデータのトランスポートも、許可されています。仕様はAAAに関連していない場合は、その後、RADIUSを使用しないでください。
* Assuming support for packet lengths greater than 4096 octets. Attribute designers cannot assume that RADIUS implementations can successfully handle packets larger than 4096 octets. If a specification could lead to a RADIUS packet larger than 4096 octets, then the alternatives described in Section 3.3 SHOULD be considered.
4096オクテットより大きいパケット長のための*と仮定すると、サポート。設計者は、RADIUSの実装が正常に4096オクテットより大きいパケットを扱うことができると仮定することはできません属性。仕様は4096オクテットより大きなRADIUSパケットにつながる可能性がある場合には、3.3節で説明した代替案を検討する必要があります。
* Stateless operation. The RADIUS protocol is stateless, and documents that require stateful protocol behavior without the use of the State Attribute need to be redesigned.
*ステートレス操作。 RADIUSプロトコルはステートレスであり、国家を使用せずにステートフルなプロトコルの動作を必要とする文書が再設計する必要がある属性。
* Provisioning of service in an Access-Reject. Such provisioning is not permitted, and MUST NOT be used. If limited access needs to be provided, then an Access-Accept with appropriate authorizations can be used instead.
*アクセス拒否でサービスのプロビジョニング。このようなプロビジョニングが許可されていない、と使用してはいけません。制限付きアクセスを提供する必要がある場合には、適切な権限でアクセス-受け入れる代わりに使用することができます。
* Provisioning of service in a Disconnect-Request. Such provisioning is not permitted and MUST NOT be used. If limited access needs to be provided, then a CoA-Request [RFC5176] with appropriate authorizations can be used instead.
*外しリクエストにおけるサービスのプロビジョニング。このようなプロビジョニングが許可されていないと、使用してはいけません。制限されたアクセスを提供する必要がある場合、適切な権限を持つCoAをリクエスト[RFC5176]は代わりに使用することができます。
* Lack of user authentication or authorization restrictions. In an authorization check, where there is no demonstration of a live user, confidential data cannot be returned. Where there is a link to a previous user authentication, the State Attribute SHOULD be present.
*ユーザー認証や承認の制限の欠如。ライブユーザーのないデモはありません承認チェックでは、機密データを返すことはできません。前回のユーザ認証へのリンクがある場合、状態属性が存在しなければなりません。
* Lack of per-packet integrity and authentication. It is expected that documents will support per-packet integrity and authentication.
*パケットごとの整合性と認証の欠如。文書は、パケットごとの整合性と認証をサポートすることが期待されます。
* Modification of RADIUS packet sequences. In RADIUS, each request is encapsulated in its own packet and elicits a single response that is sent to the requester. Since changes to this paradigm are likely to require major modifications to RADIUS client and server implementations, they SHOULD be avoided if possible.
* RADIUSパケットシーケンスの変更。 RADIUSでは、各要求は、それ自身のパケットにカプセル化され、要求者に送信される単一の応答を誘発します。このパラダイムへの変更は、RADIUSクライアントとサーバの実装に大幅な変更を必要とする可能性があるので、可能な場合、彼らは避けるべきです。
For further details, see Section 3.1.
詳細については、3.1節を参照してください。
A.5. Allocation of Attributes
A.5。属性の割り当て
Does the attribute have a limited scope of applicability as outlined below? If so, then the attributes SHOULD be allocated from the vendor space rather than requesting allocation from the standard space.
下記のとおり属性が適用の限られた範囲を持っていますか？もしそうなら、属性ではなく、標準的な空間から割り当てを要求よりも、ベンダー空間から割り当てられるべきです。
* attributes intended for a vendor to support their own systems and not suitable for general usage
*属性は、独自のシステムをサポートするベンダーを対象としておりません一般的な使用に適し
* attributes relying on data types not defined within RADIUS
*データの種類に依存する属性はRADIUS内で定義されていません
* attributes intended primarily for use within an SDO
SDOの中に主に使用するためのもの*属性
* attributes intended primarily for use within a group of SDOs
SDOののグループ内で主に使用するためのもの*属性
Note that the points listed above do not relax the recommendations discussed in this document. Instead, they recognize that the RADIUS data model has limitations. In certain situations where interoperability can be strongly constrained by the SDO or vendor, an expanded data model MAY be used. It is RECOMMENDED, however, that the RADIUS data model be used, even when it is marginally less efficient than alternatives.
上記のポイントは、この文書で説明する勧告をリラックスしていないことに注意してください。その代わりに、彼らはRADIUSデータモデルには限界があることを認識しています。相互運用性が強くSDOまたはベンダーによって拘束することができる特定の状況では、拡張データ・モデルを使用することができます。それがわずかに少ない効率的な代替案よりも場合でも、RADIUSデータモデルを使用すること、ただし、推奨されます。
When attributes are used primarily within a group of SDOs, and are not applicable to the wider Internet community, we expect that one SDO will be responsible for allocation from their own private vendor space.
属性は、主のSDOのグループ内で使用され、より広いインターネットコミュニティには適用されませんされているとき、私たちは1つのSDOは、独自のプライベートベンダーの空間から割り当ての責任となりますことを期待しています。
Appendix B. Complex Attributes
付録B.複合属性
This appendix summarizes RADIUS attributes with complex data types that are defined in existing RFCs.
この付録では、RADIUSは、既存のRFCで定義されている複雑なデータ型の属性をまとめたものです。
This appendix is published for informational purposes only and reflects the usage of attributes with complex data types at the time of the publication of this document.
この付録は情報提供のみを目的として発行され、このドキュメントの発行時点での複雑なデータ型の属性の使用を反映しています。
B.1. CHAP-Password
B.1。 CHAP-パスワード
[RFC2865], Section 5.3 defines the CHAP-Password Attribute, which is sent from the RADIUS client to the RADIUS server in an Access-Request. The data type of the CHAP Identifier is not given, only the one-octet length:
[RFC2865]、セクション5.3は、アクセス要求にRADIUSサーバにRADIUSクライアントから送信されたCHAP-パスワード属性を定義します。 CHAP識別子のデータ型は、唯一のオクテット長が与えられていません。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Since this is an authentication attribute, code changes are required on the RADIUS client and server to support it, regardless of the attribute format. Therefore, this complex data type is acceptable in this situation.
これは、認証属性であるので、コードの変更は関係なく、属性形式の、それをサポートするRADIUSクライアントとサーバー上で必要とされています。したがって、この複雑なデータ型は、このような状況では許容可能です。
B.2. CHAP-Challenge
B.2。 CHAPチャレンジ
[RFC2865], Section 5.40 defines the CHAP-Challenge Attribute, which is sent from the RADIUS client to the RADIUS server in an Access-Request. While the data type of the CHAP Identifier is given, the text also says:
[RFC2865]、セクション5.40は、Access-RequestにRADIUSサーバにRADIUSクライアントから送信されたCHAPチャレンジ属性を定義します。 CHAP識別子のデータ型が指定されている間、テキストも書かれています：
If the CHAP challenge value is 16 octets long it MAY be placed in the Request Authenticator field instead of using this attribute.
CHAPチャレンジ値は16オクテットである場合、それは代わりに、この属性を使用しての要求認証フィールドに配置することができる期間。
Defining attributes to contain values taken from the RADIUS packet header is NOT RECOMMENDED. Attributes should have values that are packed into a RADIUS AVP.
RADIUSパケットのヘッダから取得した値を格納するための属性を定義することは推奨されません。属性は、RADIUS AVPにパックされた値を持つ必要があります。
B.3. Tunnel-Password
B.3。トンネルパスワード
[RFC2868], Section 3.5 defines the Tunnel-Password Attribute, which is sent from the RADIUS server to the client in an Access-Accept. This attribute includes Tag and Salt fields, as well as a String field that consists of three logical sub-fields: the Data-Length (required and one octet), Password sub-fields (required), and the optional Padding sub-field. The attribute appears as follows:
[RFC2868]、セクション3.5は、アクセス・受け入れでクライアントにRADIUSサーバから送信されたトンネルパスワード属性を定義します。データ長（必須と1つのオクテット）、パスワードサブフィールド（必須）、およびオプションのパディングサブフィールド：この属性は、タグ、ソルト分野だけでなく、3つの論理サブフィールドから成る文字列フィールドを含みます。次のように属性が表示されます。
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 | Tag | Salt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Salt (cont) | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Since this is a security attribute, code changes are required on the RADIUS client and server to support it, regardless of the attribute format. However, while use of a complex data type is acceptable in this situation, the design of the Tunnel-Password Attribute is problematic from a security perspective since it uses MD5 as a cipher and provides a password to a NAS, potentially without proper authorization.
これは、セキュリティ属性であるので、コードの変更は関係なく、属性形式の、それをサポートするRADIUSクライアントとサーバー上で必要とされています。複雑なデータ型の使用は、このような状況では許容されている間、それは潜在的に、適切な許可を持たずに、暗号としてMD5を使用してNASにパスワードを提供するのでしかし、トンネルパスワード属性のデザインは、セキュリティの観点から問題があります。
B.4. ARAP-Password
B.4。 ARAP-パスワード
[RFC2869], Section 5.4 defines the ARAP-Password Attribute, which is sent from the RADIUS client to the server in an Access-Request. It contains four 4-octet values instead of having a single Value field:
[RFC2869]、セクション5.4は、アクセス要求でサーバにRADIUSクライアントから送信されたARAP - パスワード属性を定義します。これは、代わりに、単一の値フィールドを持つ4つの4オクテットの値が含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As with the CHAP-Password Attribute, this is an authentication attribute that would have required code changes on the RADIUS client and server, regardless of format.
CHAP-password属性と同じように、これは形式にかかわらず、RADIUSクライアントとサーバー上のコードの変更を必要とした認証属性です。
B.5. ARAP-Features
B.5。 ARAP-特長
[RFC2869], Section 5.5 defines the ARAP-Features Attribute, which is sent from the RADIUS server to the client in an Access-Accept or Access-Challenge. It contains a compound string of two single octet values, plus three 4-octet values, which the RADIUS client encapsulates in a feature flags packet in the Apple Remote Access Protocol (ARAP):
[RFC2869]、セクション5.5は、Access-受け入れるか、またはアクセスチャレンジでクライアントにRADIUSサーバから送信され、ARAP-特長は属性を定義します。これは、RADIUSクライアントは、Appleリモートアクセスプロトコル（ARAP）で機能フラグパケットでカプセル化する2つのオクテット値、プラス3 4オクテット値の複合文字列を、含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value1 | Value2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unlike the previous attributes, this attribute contains no encrypted component, nor is it directly involved in authentication. The individual sub-fields therefore could have been encapsulated in separate attributes.
以前の属性とは異なり、この属性には暗号化されたコンポーネントが含まれていない、またそれは直接認証に関与しています。個々のサブフィールドは、したがって、別の属性の中にカプセル化されている可能性があります。
While the contents of this attribute are intended to be placed in an ARAP packet, the fields need to be set by the RADIUS server. Using standard RADIUS data types would have simplified RADIUS server implementations and subsequent management. The current form of the attribute requires either the RADIUS server implementation or the RADIUS server administrator to understand the internals of the ARAP protocol.
この属性の内容はARAPパケットに配置されることを意図しているが、フィールドには、RADIUSサーバで設定する必要があります。標準のRADIUSデータ型を使用すると、RADIUSサーバの実装とその後の管理を単純化しているだろう。属性の現在のフォームは、RADIUSサーバの実装やARAPプロトコルの内部を理解するためのRADIUSサーバの管理者のいずれかが必要です。
B.6. Connect-Info
B.6。接続-情報
[RFC2869], Section 5.11 defines the Connect-Info Attribute, which is used to indicate the nature of the connection.
[RFC2869]、セクション5.11、接続の性質を示すために使用される接続し、情報の属性を定義します。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Even though the type is Text, the rest of the description indicates that it is a complex attribute:
タイプがテキストであっても、説明の残りの部分は、それが複雑な属性であることを示しています。
The Text field consists of UTF-8 encoded 10646 [8] characters. The connection speed SHOULD be included at the beginning of the first Connect-Info attribute in the packet. If the transmit and receive connection speeds differ, they may both be included in the first attribute with the transmit speed first (the speed the NAS modem transmits at), a slash (/), the receive speed, then optionally other information.
テキストフィールドには、UTF-8で構成されてい10646 [8]の文字をエンコード。接続速度は、パケットの最初の接続、情報の属性の先頭に含まれるべきです。送信および受信接続速度が異なる場合、それらは両方とも、第1の送信速度で最初の属性（NASモデムに送信する速度）、スラッシュ（/）に含まれていてもよい、その後必要に応じて他の情報をスピードを受け取ります。
For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
例えば、 "28800 V42BIS / LAPM" または "31200分の52000 V90"
More than one Connect-Info attribute may be present in an Accounting-Request packet to accommodate expected efforts by ITU to have modems report more connection information in a standard format that might exceed 252 octets.
複数の接続、情報の属性は、モデムが252個のオクテットを超える可能性があり、標準的な形式で複数の接続情報を報告するために持っているITUが期待する努力に対応するために、アカウンティング要求パケット内に存在することができます。
This attribute contains no encrypted component and is not directly involved in authentication. The individual sub-fields could therefore have been encapsulated in separate attributes.
この属性には暗号化されたコンポーネントが含まれていませんし、直接認証には関与しません。個々のサブフィールドは、したがって、別の属性の中にカプセル化されている可能性があります。
However, since the definition refers to potential standardization activity within ITU, the Connect-Info Attribute can also be thought of as opaque data whose definition is provided elsewhere. The Connect-Info Attribute could therefore qualify for an exception as described in Section 3.2.4.
定義はITU内の潜在的な標準化活動を意味するので、接続-info属性はまた、その定義は他の場所に提供されるような不透明なデータと考えることができます。 3.2.4項で説明したように接続し、情報の属性は、そのための例外の資格があります。
B.7. Framed-IPv6-Prefix
B.7。フレームを選ぶ-のIPv6プレフィックス
Section 2.3 of [RFC3162] defines the Framed-IPv6-Prefix Attribute, and Section 3 of [RFC4818] reuses this format for the Delegated-IPv6-Prefix Attribute; these attributes are sent from the RADIUS server to the client in an Access-Accept.
[RFC3162]のセクション2.3入り-のIPv6プレフィックスの属性を定義し、[RFC4818]のセクション3は、委任-のIPv6プレフィックスの属性は、このフォーマットを再利用します。これらの属性は、受け入れのアクセスでクライアントにRADIUSサーバから送信されます。
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 | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sub-fields encoded in these attributes are strongly related, and there was no previous definition of this data structure that could be referenced. Support for this attribute requires code changes on both the client and server, due to a new data type being defined. In this case, it appears to be acceptable to encode them in one attribute.
これらの属性でエンコードされたサブフィールドが強く関連し、参照することができ、このデータ構造の以前の定義がありませんでしたされています。この属性のサポートが原因定義されている新しいデータ型に、クライアントとサーバーの両方で、コードの変更が必要となります。この場合、1つの属性にそれらをコードにしてもよいように思われます。
B.8. Egress-VLANID
B.8。出口-VLANID
[RFC4675], Section 2.1 defines the Egress-VLANID Attribute, which can be sent by a RADIUS client or server.
[RFC4675]セクション2.1は、RADIUSクライアントまたはサーバによって送信することができる出口-VLANID属性を定義します。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
While it appears superficially to be of type Integer, the Value field is actually a packed structure, as follows:
Integer型であるように、表面的に見えますが、以下のように、値フィールドは、実際にパックされた構造です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Indic. | Pad | VLANID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length of the VLANID field is defined by the [IEEE-802.1Q] specification. The Tag Indicator field is either 0x31 or 0x32, for compatibility with the Egress-VLAN-Name, as discussed below. The complex structure of Egress-VLANID overlaps with that of the base Integer data type, meaning that no code changes are required for a RADIUS server to support this attribute. Code changes are required on the NAS, if only to implement the VLAN ID enforcement.
VLANIDフィールドの長さは[IEEE-802.1Q]仕様で定義されています。後述するようにタグインジケータフィールドは、退出-VLAN-NAMEとの互換性のために、0x31または0x32のいずれかです。退出-VLANIDの複雑な構造には、コードの変更は、この属性をサポートするために、RADIUSサーバのために必要とされないことを意味し、ベース整数データ型のものと重複します。唯一のVLAN IDの執行を実装する場合は、コードの変更は、NAS上で必要とされています。
Given the IEEE VLAN requirements and the limited data model of RADIUS, the chosen method is likely the best of the possible alternatives.
IEEE VLANの要件とRADIUSの限定されたデータモデルを考えると、選択した方法は、おそらく可能な選択肢のベストです。
B.9. Egress-VLAN-Name
B.9。出口-VLAN-名前
[RFC4675], Section 2.3 defines the Egress-VLAN-Name Attribute, which can be sent by a RADIUS client or server.
[RFC4675]セクション2.3は、RADIUSクライアントまたはサーバによって送信することができる退出-VLAN-name属性を定義します。
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 | Tag Indic. | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Tag Indicator is either the character '1' or '2', which in ASCII map to the identical values for Tag Indicator in Egress-VLANID above. The complex structure of this attribute is acceptable for reasons identical to those given for Egress-VLANID.
タグインジケータは、文字「1」または「2」、のいずれかである上記出口-VLANIDでタグインジケータのために同一の値にASCIIマップインチこの属性の複雑な構造は、出力-VLANIDに与えられたものと同一の理由のために許容可能です。
B.10. Digest-*
B.10。ダイジェスト-*
[RFC5090] attempts to standardize the functionality provided by an expired Internet-Draft [AAA-SIP], which improperly uses two attributes from the standard space without having been assigned them by IANA. This self-allocation is forbidden, as described in Section 2. In addition, the document uses nested attributes, which are discouraged in Section 2.1. The updated document uses basic data types and allocates nearly 20 attributes in the process.
[RFC5090]は不適切IANAによってそれらを割り当てられたことなく、標準的な空間から2つの属性が使用期限切れのインターネットドラフト[AAA-SIP]、によって提供される機能を標準化しようと試みます。また、セクション2で説明したように、この自己割り当ては、禁止され、ドキュメントは、セクション2.1で推奨されているネストされた属性を使用します。更新された文書は、基本データ型を使用し、プロセス内の約20の属性を割り当てます。
However, the document has seen wide-spread implementation, but [RFC5090] has not. One explanation may be that implementors disagreed with the trade-offs made in the updated specification. It may have been better to simply document the existing format and request IANA allocation of two attributes. The resulting design would have used nested attributes but may have gained more wide-spread implementation.
しかし、文書は広範囲の実装を見ているが、[RFC5090]はしていません。一つの説明は、実装者が更新仕様で作られたトレードオフに反対いる可能性があります。これは、単に既存のフォーマットを文書化し、二つの属性のIANAの割り当てを要求するために良いされている可能性があります。結果のデザインは、ネストされた属性を使用しているだろうが、より広範囲の実装を獲得している可能性があります。
Acknowledgments
謝辞
We would like to acknowledge David Nelson, Bernard Aboba, Emile van Bergen, Barney Wolff, Glen Zorn, Avi Lior, and Hannes Tschofenig for contributions to this document.
私たちは、この文書への貢献のためにデビッド・ネルソン、バーナードAboba、エミール・バンベルゲン、バーニー・ウルフ、グレン・ソーン、アビLIOR、およびハンネスTschofenigを確認したいと思います。
Authors' Addresses
著者のアドレス
Alan DeKok (editor) The FreeRADIUS Server Project http://freeradius.org/
アランDeKok（エディタ）FreeRADIUSサーバプロジェクトhttp://freeradius.org/
EMail: aland@freeradius.org
メールアドレス：aland@freeradius.org
Greg Weber Knoxville, TN 37932 USA
グレッグ・ウェーバーノックスビル、TN 37932 USA
EMail: gdweber@gmail.com
メールアドレス：gdweber@gmail.com