[要約] RFC 6158は、RADIUS（Remote Authentication Dial-In User Service）の設計ガイドラインであり、RADIUSプロトコルの実装と展開に関するベストプラクティスを提供しています。このRFCの目的は、RADIUSシステムのセキュリティ、信頼性、拡張性を向上させるための指針を提供することです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
このドキュメントは、IETF内および他の標準開発組織（SDO）内のユーザーサービス（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.
ただし、このドキュメントのアドバイスは、使用する場合を除き、役に立ちません。「MIB文書の著者およびレビュアーのガイドライン」[RFC4181]と同様に、著者は、公開またはレビューの要求（[RFC3575]に記載されている「専門家のレビュー」などのドキュメントのガイドラインに対してドキュメントをチェックすることが期待されています。）。同様に、このドキュメントはレビュアー（WG参加者または認証、承認、会計（AAA）医師[医師]など）によって使用され、レビューの一貫性が改善されることが予想されます。
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では、ガイドラインの適用性について説明し、半径の仕様の推奨レビュープロセスを定義します。セクション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サーバーARADIUS認証、承認、および会計（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によって割り当てられ、RFC 2865 [RFC2865]のセクション5で定義されている形式に従うRADIUS属性タイプスペースの標準スペースコード。
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。これらの属性は、各ベンダーの「文字列」フィールド（ベンダータイプのフィールドで識別）の一意の属性タイプのスペースを提供し、自己割り当てを行うことができます。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
このドキュメントのアドバイスは、RFC 2865 [RFC2865]、RFC 2866 [RFC2866]、およびその後の半径RFCで定義された属性エンコーディングとデータ形式に基づいて、サービスプロビジョニング、認証、または会計データをエンコードするために使用されるRADIUS属性に適用されます。
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.
このドキュメントは現在の最良のプラクティスを表しているため、既存の標準を更新または非難しません。その結果、「必須」および「そうでない」という用語の使用は、既存のドキュメントに既に存在する要件に限定されます。
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に由来するものであれ、すべての新しい半径仕様について従うことをお勧めします。そうすることで、既存のシステムに最小限の変更を必要としながら、仕様の最も広い適用可能性と相互運用性が確保されます。特に、標準スペース内の割り当てを要求する半径仕様がこれらのガイドラインに従い、できない場合にこれが不可能な理由を説明することが期待されています。
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]のセクション5.26で述べたように、ベンダー固有の属性（VSA）は、「一般的な使用に適していないベンダーが独自の拡張属性をサポートできるようにするために利用可能」です。ベンダーまたは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医師[医師]または同等のメーリングリストにメールを送信することでレビューをリクエストできます。IETFオペレーションおよび管理エリアディレクターは、レビューを完了し、AAAドクターメーリングリスト[医師]、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属性と値の定義はパブリックWebサイトで利用可能にするか、[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の公開も必要ありません。SDOまたはベンダーがレビューを取得するためだけにVSAを標準スペースに再ホストするように要求すると、標準スペースに圧力がかかり、同じサービスを提供する2つの方法を作成するため、相互運用性に有害である可能性があります。リホストするには、RADIUSデータモデルの変更が必要になる場合があります。これは、SDOまたはベンダーの仕様をサポートするつもりのない実装に影響を与えます。
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".
この初期の半径の設計決定の意味を説明するために、2種類のデータ型、つまり「基本」と「複雑」を区別します。基本データ型セクション2.1で定義されている既存の半径データ型の1つは、[RFC2865] RADIUS属性または[RFC2865] RADIUS VSAでカプセル化されています。他のすべてのデータ形式は「複雑なタイプ」です。
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のペンで定義されたベンダースペースを使用して、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.
* 1970年1月1日、00:00:00 UTC以降、ネットワークバイトの順序および数秒で32ビットの署名値としての時間。
* IPv6 address in network byte order.
* ネットワークバイトの順序でのIPv6アドレス。
* Interface-Id (8-octet string in network byte order).
* interface-id（ネットワークバイトの順序で8-OCTET文字列）。
* 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オクテット以下の長さ。これには、半径の外側に定義されたデータ構造の不透明なカプセル化が含まれます。追加の議論については、付録A.1.3も参照してください。
* UTF-8 text [RFC3629], totaling 253 octets or less in length.
* UTF-8テキスト[RFC3629]、合計253オクテット以下の長さ。
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.
タイプの文字列とテキストの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オクテット以上のテキストまたは文字列データの輸送を必要とする属性。これには、半径以外で定義されたデータ構造の不透明なカプセル化が含まれます。
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.
ベンダースペースは、ベンダー固有の属性（[RFC2865]、セクション5.26）の内容であると定義されています。ここで、ベンダー-IDは特定のベンダーのスペースを定義し、「文字列」フィールドの内容は一意の属性タイプを定義します。そのベンダーのためのスペース。そこで説明したように、一般的な使用には適していない独自の属性をサポートすることは、ベンダーと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]に従わないVSAエンコーディング、セクション5.26エンコーディングスキームは推奨されません。[RFC2865]はそれを義務付けていませんが、実装は一般に、ベンダーIDをVSAのオンザワイヤエンコードを決定するためのキーとして使用できると想定しています。したがって、ベンダーは、特定のベンダーIDに関連付けられているVSAに複数のエンコーディングを使用しないでください。複数のVSAエンコーディングを使用したいベンダーは、使用するVSAエンコードごとに1つのベンダーIDを要求する必要があります。
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 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を使用してプロビジョニングする方法を定義します。したがって、RADIUS属性仕様は、プロトコルまたはサービスを定義するドキュメントを参照することが期待されます。IETF内では、RADIUS属性の仕様を使用して、プロビジョニングされているプロトコルまたはサービスを定義しないでください。プロビジョニングにRADIUSを使用した新しいサービスは、他の場所で定義し、RADIUS仕様で参照する必要があります。
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プロトコルの変更に関する制限により、VSAはRADIUSパケットシーケンスの変更や新しいコマンドの追加など、RADIUS操作の基本的な側面の変更を効果的に禁止しています。ただし、VSASの非存在下でクライアントとサーバーが動作できるようにするための要件は、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は、プロトコルバリアントの開発を禁止しながら、ベンダースペース内の新しい属性の開発にかなりの緯度を提供します。この柔軟性は、機能性の損失（そしておそらくゲインでさえ）なしでベンダースペース内で多くの場合、半径属性を開発できることを意味します。
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と本質的に互換性があり、再設計する必要があります。状態属性の使用を取り巻く追加の議論については、[RFC5080]、セクション2.1.1を参照してください。
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 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.
[RFC5080]、セクション2.6に記載されているように、Access-rejectの意図は、要求されたサービスへのアクセスを拒否することです。その結果、RADIUSでは、アクセス抵抗または切断リケスト内のサービスのプロビジョニングを許可しません。アクセス拒否または切断リケスト内のサービスのプロビジョニングを含むドキュメントは、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およびセッション識別属性のみを含める必要があります。他の属性が切断要求に含まれている場合、実装は切断されたものを送信する必要があります。値「サポートされていない属性」を持つエラー（サポートされていない属性」が含まれる場合があります。
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 Access-Requestには、アクセスリケストを以前のユーザー認証にリンクするユーザー認証属性または状態属性が含まれない場合があります。承認チェックとして知られるこのようなアクセス要求は、ライブユーザーに対応するという保証を提供しません。機密情報（トンネルパスワードなど）を含む属性を定義するRADIUS仕様は、そのような属性が承認チェックに応じて返されることを禁止するように注意する必要があります。また、[RFC5080]、セクション2.1.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 Access-Requestパケットの認証と整合性の保護を必要としませんでしたが、その後の認証メカニズムの仕様[RFC3579]や消化認証[RFC5090]は、特定の半径パケットの認証と整合性保護を義務付けています。[RFC5080]、セクション2.1.1は、承認チェックを実行するアクセスリクエストパケットを含むすべてのアクセスリケストパケットにこの動作を推奨しています。新しい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パケットヘッダーの長さフィールドは、[RFC2865]セクション3で定義されています。半径パケットの最大長は4096オクテットであることがわかります。その結果、属性設計者は、半径の実装が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パケットの輸送は、ネットワークデバイスでテストが不十分なコードパスのように見えます。一部のデバイスは、断片化された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つが推奨されます。
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認証には、アクセスリケスト/アクセスチャレンジパケットのシーケンスが使用されます。これを実行可能にするためには、属性設計者は、アクセスチャレンジパケット内でかなりのスペースを消費できる属性を含めることを可能にする必要があります。既存のNASEとの互換性を維持するには、アクセスチャレンジパケットの使用を許可する必要があります（radius/EAP、[RFC3579]で定義されている）またはアクセスチャレンジの受領のサポートは、NASによって示される必要があります（半径の位置[RFC5580]）。また、仕様では、属性分割をどのように信号するか、およびステートフルな操作を必要とせずに、シーケンスに含まれる属性をどのように解釈するかを明確に説明する必要があります。残念ながら、以前の仕様は必ずしも必要な先見性を示しているわけではありません。たとえば、非常に大きなフィルタールールが考えられますが、[RFC4849]で定義されているNASフィルタールール属性は、アクセスチャレンジパケットでは許可されておらず、NASフィルタールール属性のセットを許可するメカニズムも指定されていません。Access-Request/Access-Challengeシーケンスに分割する。
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.
RADIUS会計の場合、大量のデータを輸送するには、一連の会計要請パケットが必要です。RADIUSアカウンティングクライアントを変更するには、属性ストリームを複数のアカウンティング要求に分割する必要があり、請求サーバーを変更して属性ストリームを再組み立てして解釈する必要があるため、これはRADIUSへのわずかな変更です。
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]、セクション5.11で定義されているフィルターID属性です。これにより、事前に分割されたフィルタールールのセットが名前で参照されます。
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.
3. [RFC4821]で指定されているように、パケット化レイヤーパスMTU発見技術の利用。上記のテクニックを機能させることができない最後の手段として、[RFC4821]に記載されているテクニックを適用して、RADIUSクライアントとホームサーバーの間のパスでサポートされている最大半径パケットサイズを発見することが可能かもしれません。このようなアプローチは、一連のパケットの使用の複雑さを回避できますが、動的な発見は時間がかかる可能性が高く、既存の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.
[RFC2865]では新しい名前を定義せずに、[RFC2865]で定義されていないタイプ名を使用して、その後のRADIUS仕様が定義された属性を定義します。[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属性の仕様は、ドキュメントの先頭に新しく作成されたデータ型を明示的に定義し、各属性に使用されるデータ型を明確に示すことをお勧めします。
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アドレス属性は、ドキュメントのタイプ「アドレス」として参照されます。これは、[RFC2865]で定義された「アドレス」タイプと同様の名前であり、IPv4アドレスのみを参照するように定義されています。
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プレフィックスをカプセル化する属性がすでに使用されていることを考えると、[RFC2865]で定義されたタイプに加えて、RADIUSサーバーの実装に基本的なタイプとしてサポートを含めることをお勧めします。特定のIPv6アドレスを表す意図がある場合、「IPv6アドレス」タイプを使用する必要があります。IPv6アドレスを表すために、プレフィックス長128の「IPv6プレフィックス」タイプを使用することは可能ですが、この使用法は推奨されません。フレーム付きInterface-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]半径VSAの場合、ベンダー固有の属性のオーバーヘッドが追加されているため、文字列とテキストタイプの長さの制限は253オクテットではなく247オクテットです。
[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.
タグ付けメカニズムのその他の制限は、整数値がタグ付けされている場合、値部分が3バイトに縮小され、24ビットの数値のみが表現できることです。タグ付けメカニズムは、ネストされた属性グループを作成する能力を提供しません。一部の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プロトコル設計の基本的な目標の1つは、サーバーコードの変更を必要とせずに、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サーバーポリシー言語の制限によるものであり、一般に、既存のデータ型の制限された操作（比較や算術操作など）を提供します。通常、既存の半径ポリシー言語の多くは、サブ要素を解析したり、より洗練された一致機能を提供したりすることはできません。
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.
複雑なタイプに対する推奨事項のもう1つの例外は、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ドキュメントの属性定義に、データのサブパートの描写フィールドが含まれているかどうかです。これらのフィールドを半径で描写する必要がある場合、データは半径に不透明ではなく、個々の半径属性に分離する必要があります。
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.
既存の半径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:
半径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）のメカニズムを定義し、グローバル属性タイプの割り当てではなく、その使用を奨励する必要があります。
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.
それにもかかわらず、相互運用性が有用であるだけでなく、必要な状況では、ベンダースペースで多くの新しい属性が定義されています。たとえば、IETF外のSDO（IEEE 802や第3世代パートナーシッププロジェクト（3GPP）など）には、ベンダーIDが割り当てられており、定義されているように、独自のVSAエンコードを定義し、ベンダースペース内でベンダースペース内でベンダータイプを割り当てることができます。彼らのユニークなベンダー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.
ベンダーや他のSDOが使用するのに適した「エンタープライズ」オブジェクト識別子（OID）スペースを定義するSNMPと同様に、ベンダー固有の属性の定義は、IETF以外の標準活動の一部として一般的な発生となっています。効率の理由から、標準の管理に必要な半径属性が標準自体を開発する同じSDO内で開発される場合が最も簡単です。「IETFブリッジMIB WGからIEEE 802.1 WGへのMIB作業の転送」[RFC4663]で述べたように、今日では、SDOに参加するために個人に同時に資金を提供し、基準を完了し、IETFに参加するためにIETFに参加することをいとわないベンダーはほとんどいません。関連する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.
ベンダーとSDOは、[RFC3575]、セクション2.1に記載されているように、列挙された属性の標準空間と列挙された値空間がIETFを介して公開された作業を通じて割り当てのために予約されていることを思い出させます。過去には、一部のベンダーと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で定義されているように、独自のベンダースペースにある必要があります。
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属性に適用されるこのドキュメントの規定は、マルチベンダーの使用にも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に記載されているように、ベンダーはVSAを利用して「ベンダーの半径の実装に特有の機能を定義するためにVSAを利用することが奨励されています。グローバル属性タイプの割り当ての代わりに奨励する必要があります」。
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プロセスを介してではなく、ベンダースペースから属性を割り当てるためのベンダーの推奨事項は、ベンダーが独自の半径仕様に対する変更制御を主張したいという認識です。この変更制御は、ベンダー固有の属性内でベンダー-IDとして使用するためにインターネットに割り当てられた番号当局（IANA）からペンを要求することで取得できます。ベンダーは、そのベンダー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:
半径の利用率が拡大したことを考えると、IETF内でのすべての半径作業を達成するためにSDOが必要になることは、本質的に非効率的で無効であることが明らかになりました。したがって、SDO RADIUS属性の仕様は、以下の基準のいずれかを一致させる属性にRADIUS標準スペースからの割り当てを要求するのではなく、ベンダー空間から属性を割り当てることをお勧めします。
* Attributes relying on data types not defined within 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].
インターネットコミュニティの幅広いスペクトルにわたる相互運用可能な使用を目的とした新しい半径属性または値は、[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.
IETFプロセスを介してではなく、ベンダースペースから属性を割り当てるためのSDOSの推奨事項は、SDOSが独自の半径仕様に対する変更制御を主張したいという認識です。この変更制御は、ベンダー固有の属性内でベンダー-IDとして使用するためにインターネットに割り当てられた番号当局（IANA）からペンを要求することで取得できます。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 Server Dictionaryエントリは通常静的であり、動的条件に基づいて形式を変更することをサポートせずに、ユーザーが属性の内容を入力できるようにします。ただし、静的タイプに関するこの制限は、受信属性の内容に基づいて異なる属性を返すポリシーを実装することを妨げません。これは、既存の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].
この仕様は、認証、承認、会計で使用される半径属性の設計に関するガイドラインを提供します。このアプリケーションの脅威とセキュリティの問題は、[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.
属性ごとに半径属性を難読化することが必要です。これの現在の標準メカニズムは、[RFC2865]、セクション5.2（ユーザーパスワード値を不明瞭にするため）に記載されており、[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 140 [FIPS]で証明できることをお勧めします。
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属性を介して提供されます。[RFC3579]のセクション3.2および[RFC5080]のセクション2.2.2も参照してください。これには、クライアントの実装には、すべてのAccess-RequestにメッセージAuthenticator属性を含める必要があります。
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]のセクション4および[RFC3580]のセクション5を参照してください。
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 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.
半径システムに由来する不透明なデータを消費するシステムは、その半径システムから適切に分離され、最小限の特権で実行される必要があります。非ラジウスシステムの潜在的な脆弱性は、システム全体のセキュリティに最小限の影響を与えます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[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.
[RFC1155] Rose、M。およびK. McCloghrie、「TCP/IPベースのインターネットの管理情報の構造と識別」、STD 16、RFC 1155、1990年5月。
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", RFC 1157, May 1990.
[RFC1157] Case、J.、Fedor、M.、Schoffstall、M。、およびJ. Davin、「Simple Network Management Protocol（SNMP）」、RFC 1157、1990年5月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548] Zorn、G。、「Microsoft Vendor固有の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 Accounting」、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] Zorn、G.、Leifer、D.、Rubens、A.、Shriver、J.、Holdrege、M。、およびI. Goyret、「トンネルプロトコルサポートのRadius属性」、RFC 2868、2000年6月。
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869] Rigney、C.、Willats、W。、およびP. Calhoun、「Radius Extensions」、RFC 2869、2000年6月。
[RFC2882] Mitton, D., "Network Access Servers Requirements: Extended RADIUS Practices", RFC 2882, July 2000.
[RFC2882] Mitton、D。、「ネットワークアクセスサーバー要件：拡張RADIUSプラクティス」、RFC 2882、2000年7月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、Zorn、G。、およびD. Mitton、「Radius and 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. Calhoun、「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.、Smith、A.、Zorn、G。、およびJ. Roese、「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] Heard、C.、ed。、「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] Harrington、D。、「IETF Bridge MIB WGからIEEE 802.1 WGへのMIB作業の転送」、RFC 4663、2006年9月。
[RFC4675] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Attributes for Virtual LAN and Priority Support", RFC 4675, September 2006.
[RFC4675] Congdon、P.、Sanchez、M。、およびB. Aboba、「仮想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.、Zorn、G.、Arberg、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 Delegated-IPv6-Prefix属性」、RFC 4818、2007年4月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年3月。
[RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter Rule Attribute", RFC 4849, April 2007.
[RFC4849] Congdon、P.、Sanchez、M。、およびB. Aboba、「Radius Filter Rule属性」、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] Nelson、D。およびA. Dekok、「一般的なリモート認証ダイヤルインユーザーサービス（RADIUS）実装の問題と提案された修正」、RFC 5080、2007年12月。
[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.、Schwartz、D.、Williams、D.、およびW. Beck、「Digest認証のための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.
[RFC5176] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D.、およびB. Aboba、「Remote Authentication Dial in User Service（RADIUS）への動的認証拡張」、RFC 5176、2008年1月。
[DOCTORS] AAA Doctors Mailing List, www.ietf.org/mail-archive/web/aaa-doctors.
[医師] AAA Doctorsメーリングリスト、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] FIPS 140-3（ドラフト）、「暗号化モジュールのセキュリティ要件」、http：//csrc.nist.gov/publications/pubsfips.html。
[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標準：仮想ブリッジ付きローカルエリアネットワークのドラフト標準、P802.1Q-2003、2003年1月。
[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.、ed。、Adrangi、F.、Jones、M.、Lior、A。、およびB. Aboba、「Radius and Aimeterで位置オブジェクトを運ぶ」、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.、Schwartz、D.、Williams、D.、およびW. Beck、「Digest認証のためのRadius Extension」、2004年11月の作業。
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プロトコルで使用される属性の設計に関するガイドラインを提供します。これらのガイドラインに従う仕様は、既存のシステムを最小限に抑えて最大の相互運用性を実現することが期待されます。
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データ型のいずれかを使用する[RFC2865]形式のRADIUS VSAにカプセル化する必要があります。
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.
RADIUSサーバーによって解析されることを意図していない認証および/またはセキュリティデータを運ぶデータ型は、セクション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サーバー（プロキシを含む）によって不透明なデータとして扱うことができますか？両方の質問に積極的に回答できる場合、半径の仕様で複雑な構造を使用できます。
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.
属性の仕様は、型文字列のカプセル化属性を定義する必要があります。仕様は、構造を定義する外部ドキュメントを参照する必要があります。セクション3.2.3で説明されている理由により、仕様は構造を定義または記述しないでください。
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に記載されている既存の複雑なデータ型を使用できます。
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では、より複雑なデータ型について説明します。これは、基本データ型を使用して複数の属性に置き換える必要があります。
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.
* あらゆるサイズの署名整数。使用しないでください。1つ以上の署名されていない整数属性に置き換える必要があります。属性の定義には、そうでなければ整数の符号値に入る情報を含めることができます。
* 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.
* マルチフィールドテキスト文字列。各フィールドは、別の属性にカプセル化する必要があります。
* 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）。属性は、フラットタイプスペースで定義する必要があります。
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も参照してください。
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エンコードは[RFC2865]、セクション5.26エンコードに置き換える必要があります。
* 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.
* タイプレングス価値形式ではないベンダー固有のコンテンツ。使用しないでください。ベンダー固有の属性は、タイプレングス値形式である必要があります。
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で提案されているエンコードに従う必要があります。非標準エンコーディングへのベンダー拡張は、相互運用性に悪影響を与える可能性があるため、推奨されません。
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:
以下のリストに概説されているように、仕様は半径操作モデルを変更しますか？もしそうなら、設計目標を達成する別の方法を使用する必要があります。潜在的な問題領域には、以下が含まれます。
* 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を使用します。RADIUSを使用して、EAPなどの認証方法を輸送することは、これらの方法が比較的大量のデータを輸送する必要がある場合でも、明示的に許可されています。セクション3.2.3で説明したように、AAAに関連する不透明なデータの輸送も許可されています。ただし、仕様がAAAに関連していない場合、半径を使用しないでください。
* 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オクテットを超える半径パケットにつながる可能性がある場合、セクション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-Request [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クライアントとサーバーの実装に大きな変更が必要になる可能性が高いため、可能であれば避ける必要があります。
For further details, see Section 3.1.
詳細については、セクション3.1を参照してください。
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
* 半径内で定義されていないデータ型に依存する属性
* 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が独自のプライベートベンダースペースからの割り当てを担当することを期待しています。
This appendix summarizes RADIUS attributes with complex data types that are defined in existing RFCs.
この付録は、既存の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.
この付録は、情報目的のみで公開されており、このドキュメントの公開時に複雑なデータ型を持つ属性の使用を反映しています。
[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クライアントからAccess-RequestのRADIUSサーバーに送信されるChap-Password属性を定義します。CHAP識別子のデータ型は指定されておらず、1オクテットの長さのみが与えられていません。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 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クライアントとサーバーでコードの変更が必要です。したがって、この状況では、この複雑なデータ型は受け入れられます。
[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は、RADIUSクライアントからAccess-RequestのRADIUSサーバーに送信されるChap-Challenge属性を定義します。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 Challenge Valueの長さが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パケットヘッダーから取得した値を含む属性を定義することは推奨されません。属性には、半径AVPに詰め込まれた値が必要です。
[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は、Access-AcceptでRADIUSサーバーからクライアントに送信されるトンネルパスワード属性を定義します。この属性には、タグと塩のフィールド、および3つの論理サブフィールドで構成されるストリングフィールドが含まれます。データ長（必須と1つのオクテット）、パスワードサブフィールド（必須）、およびオプションのパディングサブフィールドです。属性は次のように表示されます。
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クライアントとサーバーでコードの変更が必要です。ただし、この状況では複雑なデータ型の使用は受け入れられますが、Tunnel-Password属性の設計は、MD5を暗号として使用し、NASにパスワードを提供するため、セキュリティの観点から問題があります。
[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は、ARAP-PASSWORD属性を定義します。これは、RADIUSクライアントからAccess-Requestでサーバーに送信されます。単一の値フィールドを持つ代わりに、4つの4-OCTET値が含まれています。
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.
[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では、ARAP-Features属性を定義します。これは、ARAP-FEITURES属性を、Access-AcceptまたはAccess-ChallengeでRADIUSサーバーからクライアントに送信します。2つの単一のオクテット値の複合文字列と、RADIUSクライアントがApple Remote Access Protocol（ARAP）の機能フラグパケットにカプセル化する3つの4-OCTET値が含まれています。
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サーバーの実装とその後の管理が簡素化されます。属性の現在のフォームには、ARAPプロトコルの内部を理解するために、RADIUSサーバーの実装またはRADIUSサーバー管理者のいずれかが必要です。
[RFC2869], Section 5.11 defines the Connect-Info Attribute, which is used to indicate the nature of the connection.
[RFC2869]、セクション5.11は、接続の性質を示すために使用される接続INFO属性を定義しています。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
テキストフィールドは、10646 [8]文字をエンコードしたUTF-8で構成されています。接続速度は、パケットの最初の接続INFO属性の先頭に含める必要があります。送信および受信速度が異なる場合、それらは両方とも最初に送信速度（NASモデムが送信する速度）、スラッシュ（/）、受信速度、次にオプションで他の情報を含む最初の属性に含めることができます。
For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
たとえば、「28800 V42BIS/LAPM」または「52000/31200 V90」
More than one Connect-Info attribute may be present in an Accounting-Request packet to accommodate expected efforts by ITU to have modems report more connection information in a standard format that might exceed 252 octets.
ITUによる予想される取り組みに対応するために、252オクテットを超える可能性のある標準形式でより多くの接続情報を報告するために、ITUによる予想される努力に対応するために、コンセントRequestパケットに複数のConnect-INFO属性が存在する場合があります。
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内の潜在的な標準化アクティビティを指しているため、Connect-INFO属性は、定義が他の場所に提供される不透明なデータとも考えることができます。したがって、Connect-INFO属性は、セクション3.2.4で説明されているように、例外の対象となる可能性があります。
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は、[RFC4818]のフレーム付き-IPV6-PREFIX属性を定義し、委任されたIPV6-PREFIX属性のこの形式を再利用します。これらの属性は、Access-Acceptで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.
[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:
表面的には整数型のように見えますが、値フィールドは実際には次のように詰め込まれた構造です。
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]仕様によって定義されます。以下で説明するように、Egress-Vlan-Nameとの互換性のために、タグインジケータフィールドは0x31または0x32のいずれかです。出力 - ヴラニドの複雑な構造は、ベース整数データ型の構造と重複しています。つまり、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の限られたデータモデルを考えると、選択された方法は、可能な選択肢の最良のものである可能性があります。
[RFC4675], Section 2.3 defines the Egress-VLAN-Name Attribute, which can be sent by a RADIUS client or server.
[RFC4675]、セクション2.3は、RADIUSクライアントまたはサーバーによって送信できるEgress-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.
タグインジケーターは、ASCIIでは上記のEgress-Vlanidのタグインジケーターの同一の値にマップする文字「1」または「2」のいずれかです。この属性の複雑な構造は、出口vlanidと同一の理由で許容されます。
[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]は、有効期限が切れたインターネットドラフト[AAA-SIP]によって提供される機能を標準化しようとします。これは、IANAによって割り当てられずに標準空間から2つの属性を不適切に使用します。セクション2で説明されているように、この自己配置は禁止されています。さらに、ドキュメントはネストされた属性を使用します。更新されたドキュメントは、基本的なデータ型を使用し、プロセスで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]は実装していません。1つの説明は、実装者が更新された仕様で行われたトレードオフに反対したことです。既存の形式を単純に文書化し、2つの属性の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.
デビッド・ネルソン、バーナード・アボバ、エミール・ヴァン・ベルゲン、バーニー・ウルフ、グレン・ゾーン、アヴィ・リオール、ハンヌ・ツェコフェニグにこの文書に貢献してくれたことを認めたいと思います。
Authors' Addresses
著者のアドレス
Alan DeKok (editor) The FreeRADIUS Server Project http://freeradius.org/
Alan Dekok（編集者）Freeradius Server Project http://freeradius.org/
EMail: aland@freeradius.org
Greg Weber Knoxville, TN 37932 USA
グレッグウェーバーノックスビル、テネシー州37932 USA
EMail: gdweber@gmail.com