[要約] RFC 2903は、汎用のAAAアーキテクチャに関する要約と目的を提供しています。このRFCの目的は、AAAシステムの設計と実装に関するガイドラインを提供し、ネットワークセキュリティとアクセス制御の向上を促進することです。
Network Working Group C. de Laat
Request for Comments: 2903 Utrecht University
Category: Experimental G. Gross
Lucent Technologies
L. Gommans
Enterasys Networks EMEA
J. Vollbrecht
D. Spence
Interlink Networks, Inc.
August 2000
Generic AAA Architecture
一般的なAAAアーキテクチャ
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This memo proposes an Authentication, Authorization, Accounting (AAA) architecture that would incorporate a generic AAA server along with an application interface to a set of Application Specific Modules that could perform application specific AAA functions. A separation of AAA functions required in a multi-domain environment is then proposed using a layered protocol abstraction. The long term goal is to create a generic framework which allows complex authorizations to be realized through a network of interconnected AAA servers.
このメモは、一般的なAAAサーバーとアプリケーション固有のAAA機能を実行できるアプリケーション固有のモジュールのセットに、一般的なAAAサーバーを組み込む認証、承認、会計（AAA）アーキテクチャを提案します。次に、マルチドメイン環境で必要なAAA関数の分離が、層状プロトコル抽象化を使用して提案されます。長期的な目標は、相互接続されたAAAサーバーのネットワークを介して複雑な承認を実現できる一般的なフレームワークを作成することです。
Table of Contents
目次
1. Introduction ................................................ 2
2. Generic AAA Architecture .................................... 4
2.1. Architectural Components of a Generic AAA Server ....... 4
2.1.1. Authorization Rule Evaluation ................... 4
2.1.2. Application Specific Module (ASM) ............... 5
2.1.3. Authorization Event Log ......................... 6
2.1.4. Policy Repository ............................... 6
2.1.5. Request Forwarding .............................. 6
2.2. Generic AAA Server Model ............................... 6
2.2.1. Generic AAA Server Interactions ................. 7
2.2.2. Compatibility with Legacy Protocols ............. 7
2.2.3. Interaction between the ASM and the Service ..... 9
2.2.4. Multi-domain Architecture ....................... 10
2.3. Model Observations ..................................... 10
2.4. Suggestions for Future Work ............................ 11
3. Layered AAA Protocol Model .................................. 12
3.1. Elements of a Layered Architecture ..................... 14
3.1.1. Service Layer Abstract Interface Primitives ..... 14
3.1.2. Service Layer Peer End Point Name Space ......... 14
3.1.3. Peer Registration, Discovery, and Location
Resolution ............................................. 14
3.1.4. Trust Relationships Between Peer End Points ..... 14
3.1.5. Service Layer Finite State Machine .............. 15
3.1.6. Protocol Data Unit Types ........................ 15
3.2. AAA Application Specific Service Layer ................. 15
3.3. Presentation Service Layer ............................. 16
3.4. AAA Transaction/Session Management Service Layer ....... 17
3.5. AAA-TSM Service Layer Program Interface Primitives ..... 20
3.6. AAA-TSM Layer End Point Name Space ..................... 21
3.7. Protocol Stack Examples ................................ 22
4. Security Considerations ..................................... 22
Glossary ....................................................... 23
References ..................................................... 24
Authors' Addresses ............................................. 24
Full Copyright Statement ....................................... 26
The work for this memo was done by a group that originally was the Authorization subgroup of the AAA Working Group of the IETF. When the charter of the AAA working group was changed to focus on MobileIP and NAS requirements, the AAAarch Research Group was chartered within the IRTF to continue and expand the architectural work started by the Authorization subgroup. This memo is one of four which were created by the subgroup. This memo is a starting point for further work within the AAAarch Research Group. It is still a work in progress and is published so that the work will be available for the AAAarch subgroup and others working in this area, not as a definitive description of architecture or requirements.
このメモの作業は、もともとIETFのAAAワーキンググループの承認サブグループであったグループによって行われました。AAAワーキンググループの憲章がMobileIPおよびNASの要件に焦点を当てるように変更されたとき、AAAARCH Research GroupはIRTF内でチャーターされ、Authorizationサブグループが開始したアーキテクチャ作業を継続および拡大しました。このメモは、サブグループによって作成された4つのメモの1つです。このメモは、AAARACH Research Group内でのさらなる作業の出発点です。これはまだ進行中の作業であり、AAAARCHサブグループやこの分野で働いている他の人々がアーキテクチャや要件の決定的な説明としてではなく、作業が利用可能になるように公開されています。
The authorization subgroup of the AAA Working Group proposed an "AAA Authorization Framework" [2] illustrated with numerous application examples [3] which in turn motivates a proposed list of authorization requirements [4]. This memo builds on the framework presented in [2] by proposing an AAA infrastructure consisting of a network of cooperating generic AAA servers communicating via a standard protocol. The protocol should be quite general and should support the needs of a wide variety of applications requiring AAA functionality. To realize this goal, the protocol will need to operate in a multi-domain environment with multiple service providers as well as entities taking on other AAA roles such as User Home Organizations and brokers. It should be possible to combine requests for multiple authorizations of different types in the same authorization transaction. The AAA infrastructure will be required to forward the components of such requests to the appropriate AAA servers for authorization and to collect the authorization decisions from the various AAA servers consulted. All of this activity is perfectly general in nature and can be realized in the common infrastructure.
AAAワーキンググループの承認サブグループは、「AAA認可フレームワーク」[2]を提案しました[2]。このメモは、標準プロトコルを介して通信する一般的なAAAサーバーのネットワークで構成されるAAAインフラストラクチャを提案することにより、[2]で提示されたフレームワークに基づいて構築されます。プロトコルは非常に一般的である必要があり、AAA機能を必要とするさまざまなアプリケーションのニーズをサポートする必要があります。この目標を実現するには、プロトコルは、複数のサービスプロバイダーや、ユーザーホーム組織やブローカーなどの他のAAAの役割を担当するエンティティを備えたマルチドメイン環境で動作する必要があります。同じ承認トランザクションで、異なるタイプの複数の承認のリクエストを組み合わせることができるはずです。AAAインフラストラクチャは、そのような要求のコンポーネントを適切なAAAサーバーに承認のために転送し、相談したさまざまなAAAサーバーから承認決定を収集する必要があります。この活動はすべて、本質的に完全に一般的であり、共通のインフラストラクチャで実現できます。
But the applications requiring AAA services will each have their own unique needs. After a service is authorized, it must be configured and initialized. This will require application specific knowledge and may require application specific protocols to communicate with application specific service components. To handle these application specific functions, we propose an application interface between a generic AAA server and a set of one or more Application Specific Modules (ASMs) which can carry out the unique functionality required by each application.
しかし、AAAサービスを必要とするアプリケーションには、それぞれ独自のニーズがあります。サービスが承認された後、構成および初期化する必要があります。これには、アプリケーション固有の知識が必要であり、アプリケーション固有のサービスコンポーネントと通信するためのアプリケーション固有のプロトコルが必要になる場合があります。これらのアプリケーション固有の機能を処理するために、一般的なAAAサーバーと、各アプリケーションで必要な一意の機能を実行できる1つ以上のアプリケーション固有モジュール（ASM）のセットとの間のアプリケーションインターフェイスを提案します。
Since the data required by each application for authentication, authorization, or accounting may have unique structure, the standard AAA protocol should allow the encapsulation of opaque units of Application Specific Information (ASI). These units would begin with a standard header to allow them to be forwarded by the generic infrastructure. When delivered to the final destination, an ASI unit would be passed by a generic AAA server across its program interface to an appropriate ASM for application specific processing. Nevertheless, it remains a goal of the design for information units to be encoded in standard ways as much as possible so as to enable processing by a generic rule based engine.
認証、承認、または会計のために各アプリケーションが必要とするデータには一意の構造がある可能性があるため、標準のAAAプロトコルは、アプリケーション固有の情報（ASI）の不透明ユニットのカプセル化を可能にする必要があります。これらのユニットは、一般的なインフラストラクチャによって転送できるようにする標準ヘッダーから始まります。最終宛先に配信されると、ASIユニットは、プログラムインターフェイス全体で一般的なAAAサーバーによって、アプリケーション固有の処理のために適切なASMに渡されます。それにもかかわらず、一般的なルールベースのエンジンによる処理を可能にするために、情報ユニットを可能な限り標準的な方法でエンコードすることの設計の目標のままです。
The interactions of the generic AAA server with the Application Specific Modules and with each other to realize complex AAA functions is explored in section 2. Then, in section 3, we attempt to further organize the AAA functions into logical groups using a protocol layering abstraction. This abstraction is not intended to be a reference model ready to be used for protocol design. At this point in the work, there are numerous questions that need to be addressed and numerous problems that remain to be solved. It may be that an abstraction other than layering will prove to be more useful or, more likely, that the application layer will require some substructure of its own.
一般的なAAAサーバーとアプリケーション固有のモジュールと互いに相互作用して、複雑なAAA関数を実現するための相互作用をセクション2で検討します。次に、セクション3では、プロトコル階層化抽象化を使用してAAA関数を論理グループにさらに整理しようとします。この抽象化は、プロトコル設計に使用する準備ができている参照モデルではありません。作業のこの時点で、対処する必要がある多くの質問と解決されていない多くの問題があります。レイヤー化以外の抽象化は、より有用であることが証明されるか、アプリケーションレイヤーが独自の部分構造を必要とする可能性が高い場合があります。
Finally, in section 4, we show how the security requirements identified in [4] can be met in the generic server and the Application Specific Modules by applying security techniques such as public key encryption or digital signatures to the Application Specific Information units individually, so that different stakeholders in the AAA server network can protect selected information units from being deciphered or altered by other stakeholders in an authentication, authorization, or accounting chain.
最後に、セクション4では、[4]で特定されたセキュリティ要件が、一般的なキー暗号化やデジタル署名などのセキュリティ手法をアプリケーション固有の情報ユニットに個別に適用することにより、[4]で特定されたセキュリティ要件をどのように満たすことができるかを示します。AAAサーバーネットワークのさまざまな利害関係者は、選択された情報ユニットが認証、承認、または会計チェーンで他の利害関係者によって解読または変更されるのを防ぐことができます。
For the long term we envision a generic AAA server which is capable of authenticating users, handling authorization requests, and collecting accounting data. For a service provider, such a generic AAA server would be interfaced to an application specific module which manages the resource for which authorization is required. Generic AAA components would also be deployed in other administrative domains performing authorization functions.
長期的には、ユーザーを認証し、承認リクエストを処理し、会計データを収集できる一般的なAAAサーバーを想定しています。サービスプロバイダーの場合、そのような一般的なAAAサーバーは、許可が必要なリソースを管理するアプリケーション固有のモジュールにインターフェースされます。一般的なAAAコンポーネントは、認証関数を実行する他の管理ドメインに展開されます。
The first step in the authorization process is for the user or an entity operating on the user's behalf to submit a well-formatted request to an AAA server. A generic AAA server has rules (logic and/or algebraic formulas) to inspect the request and come to an authorization decision. The first problem which arises is that Application Specific Information (ASI) has to be separated from the underlying logic for the authorization. Ideally the AAA server would have a rule based engine at this point which would know the logic rules and understand some generic information in the request, but it would not know anything about application specific information except where this information can be evaluated to give a boolean or numerical value. It should be possible to create rules that refer to data elements that were not considered when the application was created. For example, one could request to do a remote virtual control room experiment from home using a dialin provider. The request would only be successful if the dialin access server allows it and if there is bandwidth available (bandwidth broker) and if the experimenter has the money to pay for it (E-Commerce). Possibly the people who specified the bandwidth broker protocol did not think of combining quality of service with a network service authorization in a single AAA request, but this generic model would allow it.
承認プロセスの最初のステップは、ユーザーまたはユーザーに代わって動作するエンティティが、AAAサーバーに適切にフォーマットされたリクエストを送信することです。一般的なAAAサーバーには、リクエストを検査し、承認決定を下すためのルール（ロジックおよび/または代数式）があります。最初に発生する問題は、アプリケーション固有の情報（ASI）を承認のために基礎となるロジックから分離する必要があることです。理想的には、AAAサーバーはこの時点でロジックルールを知っており、リクエストの一般的な情報を理解するルールベースのエンジンを持っていますが、この情報を評価してブールまたはブールを与えることができる場合を除き、アプリケーション固有の情報については何も知りません。数値。アプリケーションが作成されたときに考慮されていないデータ要素を指すルールを作成することが可能です。たとえば、ダイヤリンプロバイダーを使用して、自宅からリモート仮想コントロールルームの実験を行うことを要求できます。ダイヤリンアクセスサーバーが許可され、帯域幅（帯域幅ブローカー）がある場合、および実験者がそれを支払うお金（eコマース）を持っている場合にのみ、リクエストが成功します。おそらく、帯域幅のブローカープロトコルを指定した人は、サービスの品質を単一のAAAリクエストでネットワークサービス承認と組み合わせることを考えていませんでしたが、この汎用モデルはそれを許可します。
+------+ +-------+ +-------+ +-------+ +-------+
| | auth | | auth | | auth | | auth | |
| |<---->| AAA |<---->| AAA |<---->| AAA |<---->| AAA |
| | | | | | | | | |
| | +-------+ +-------+ +-------+ +-------+
| User | | | | |
| | | +-------+ +-------+ +-------+
| | | | BB | | BB | |Budget |
| | | +-------+ +-------+ +-------+
| | | | |
| | +-------+ | |
| | |dial in| +-------+ +-------+
| |<====>|service|<====>|network|<====>|network|<===> Experiment
+------+ +-------+ +-------+ +-------+
user <-> dialin <-> backbone with BB <-> <remote experiment>
Fig. 1 -- Example of a Multi Domain Multi Type of Server Request
図1-マルチドメインの例マルチタイプのサーバーリクエスト
Ultimately an AAA server needs to interact with an application specific module (ASM). In a service provider, the ASM would manage resources and configure the service equipment to provide the authorized service. It might also involve itself in the authorization decision because it has the application specific knowledge required. A user home organization (UHO) may require ASMs as well, to perform application specific user authorization functions. For example, a UHO ASM might be required to access certain application specific databases or interpret application specific service level specifications.
最終的に、AAAサーバーは、アプリケーション固有のモジュール（ASM）と対話する必要があります。サービスプロバイダーでは、ASMはリソースを管理し、サービス機器を構成して認定サービスを提供します。また、必要なアプリケーション固有の知識があるため、承認決定に関与する可能性があります。ユーザーホーム組織（UHO）は、アプリケーション固有のユーザー認証関数を実行するために、ASMも必要になる場合があります。たとえば、特定のアプリケーション固有のデータベースにアクセスするか、アプリケーション固有のサービスレベルの仕様を解釈するには、UHO ASMが必要になる場合があります。
Whatever the role of an administration relative to an authorization decision, the capabilities of the generic AAA server and the interface between it and the ASMs remains the same. This interface may be an Application Program Interface (API) or could even be a protocol based interface. In this model, however, the application specific module is regarded as as separate architectural component from the generic AAA server. As such, it must be addressable and must therefore be part of a global naming space.
認可決定に対する管理の役割が何であれ、一般的なAAAサーバーとそれとASMの間のインターフェースの能力は同じままです。このインターフェイスは、アプリケーションプログラムインターフェイス（API）であるか、プロトコルベースのインターフェイスである場合もあります。ただし、このモデルでは、アプリケーション固有のモジュールは、一般的なAAAサーバーから個別のアーキテクチャコンポーネントと見なされます。そのため、アドレス可能である必要があるため、グローバルな命名空間の一部でなければなりません。
For auditing purposes, the generic server must have some form of database to store time-stamped events which occur in the AAA server. This database can be used to account for authorizations which were given, but it can also be used in rules. One can imagine rules in which an authorization is only given if some other event was logged in the past. With the aid of certificates, this database could support non-repudiation.
監査のために、一般的なサーバーには、AAAサーバーで発生するタイムスタンプのイベントを保存するために、何らかの形式のデータベースが必要です。このデータベースは、指定された承認を考慮するために使用できますが、ルールでも使用できます。他のイベントが過去に記録された場合にのみ、許可が与えられるルールを想像できます。証明書の助けを借りて、このデータベースは非繰り返しをサポートできます。
A database containing the available services and resources about which authorization decisions can be made and the policy rules to make them is also needed. Here too, the naming space for the services and resources is important since they must be addressable from other AAA servers to be able to build complex authorization requests.
許可決定を下すことができる可能性のあるサービスとリソースを含むデータベースと、それらを作成するためのポリシールールも必要です。ここでも、サービスとリソースのための命名スペースは、複雑な承認要求を構築できるようにするために他のAAAサーバーからアドレス指定できるため、重要です。
Due to the multiple administrative domain (multi-kingdom) nature of the AAA problem, a mechanism to forward messages between AAA servers is needed. The protocol by which two AAA servers communicate should be a peer-to-peer protocol.
AAA問題の複数の管理ドメイン（マルチキングダム）性質により、AAAサーバー間でメッセージを転送するメカニズムが必要です。2つのAAAサーバーが通信するプロトコルは、ピアツーピアプロトコルである必要があります。
With the implementation of the above mentioned components, the AAA server would be able to handle AAA requests. It would inspect the contents of the request, determine what authorization is requested, retrieve the policy rules from the repository, perform various local functions, and then choose one of the following options to further process each of the components of the request:
上記のコンポーネントの実装により、AAAサーバーはAAAリクエストを処理できます。リクエストの内容を検査し、要求される許可を決定し、リポジトリからポリシールールを取得し、さまざまなローカル機能を実行し、次のオプションのいずれかを選択して、リクエストの各コンポーネントをさらに処理します。
a) Let the component be evaluated by an attached ASM.
a) 添付のASMによってコンポーネントを評価します。
b) Query the authorization event log or the policy repository for the answer.
b) 承認イベントログまたは回答のポリシーリポジトリをクエリします。
c) Forward the component(s) to another AAA server for evaluation.
c) 評価のためにコンポーネントを別のAAAサーバーに転送します。
In the following sections we present the generic model.
次のセクションでは、一般的なモデルを紹介します。
Figure 2 illustrates a generic AAA Server with connections to the various architectural components described above. In this model, the user or another AAA server contacts the AAA server to get authorization, and the AAA server interacts with the service. The request is sent to the AAA server using the future AAA protocol. The server interacts with the service via a second protocol which we have labeled as type "2" in the figure. We say no more of the type 2 protocol than that it must support some global naming space for the application specific items. The same holds for the type 3 communication used to access the repository.
図2は、上記のさまざまなアーキテクチャコンポーネントに接続する一般的なAAAサーバーを示しています。このモデルでは、ユーザーまたは別のAAAサーバーがAAAサーバーに連絡して承認を取得し、AAAサーバーはサービスと対話します。リクエストは、将来のAAAプロトコルを使用してAAAサーバーに送信されます。サーバーは、図のタイプ「2」としてラベル付けされた2番目のプロトコルを介してサービスと対話します。タイプ2のプロトコルは、アプリケーション固有のアイテムのグローバルな命名スペースをサポートしなければならないということよりも多くは言いません。リポジトリへのアクセスに使用されるタイプ3通信についても同じことが当てはまります。
+------------------+
| |
request <-----1----->|Generic AAA Server|<---1---> AAA server
|Rule based engine |
| |\
+------------------+ 3 +------------+
^ \| Policy and |
| | event |
2 | repository |
| +------------+
v
+------------------+
| Application |
| Specific |
| Module |
+------------------+
The numbers in the links denote types of communication.
リンクの数字は、通信の種類を示しています。
Fig. 2 -- Generic AAA Server Interactions
図2-ジェネリックAAAサーバーの相互作用
Because of the widespread deployment of equipment that implements legacy AAA protocols and the desire to realize the functionality of the new AAA protocol while protecting the investment in existing infrastructure, it may be useful to implement a AAA gateway function that can encapsulate legacy protocol data units within the messages of the new protocol. Use of this technique, for example, would allow Radius attribute value pairs to be encapsulated in Application Specific Information (ASI) units of the new protocol in such a way that the ASI units can be digitally signed and encrypted for end-to-end protection between a service provider's AAA server and a home AAA server communicating via a marginally trusted proxy AAA server. The service provider's NAS would communicate via Radius to the service provider's AAA server, but the AAA servers would communicate among themselves via the new AAA protocol. In this case, the AAA gateway would be a software module residing in the service provider's AAA server. Alternatively the AAA gateway could be implemented as a standalone process.
レガシーAAAプロトコルを実施する機器の広範な展開と、既存のインフラストラクチャへの投資を保護しながら、新しいAAAプロトコルの機能を実現したいという願望のため、レガシープロトコルデータユニットをカプセル化できるAAAゲートウェイ機能を実装すると便利かもしれません。新しいプロトコルのメッセージ。たとえば、この手法の使用により、ASIユニットをデジタル的に署名してエンドツーエンドの保護のために暗号化できるように、新しいプロトコルのアプリケーション固有の情報（ASI）ユニットにRADIUS属性値ペアをカプセル化することができます。サービスプロバイダーのAAAサーバーと、わずかに信頼できるプロキシAAAサーバーを介して通信するホームAAAサーバーの間。サービスプロバイダーのNASは、RADIUSを介してサービスプロバイダーのAAAサーバーに通信しますが、AAAサーバーは新しいAAAプロトコルを介して通信します。この場合、AAAゲートウェイは、サービスプロバイダーのAAAサーバーに居住するソフトウェアモジュールになります。あるいは、AAAゲートウェイをスタンドアロンプロセスとして実装することもできます。
Figure 3 illustrates an AAA gateway. Communication type 4 is the legacy protocol. Communication type 1 is the future standard AAA protocol. And communication type 2 is for application specific communication to Application Specific Modules (ASMs) or Service Equipment.
図3は、AAAゲートウェイを示しています。通信タイプ4はレガシープロトコルです。通信タイプ1は、将来の標準AAAプロトコルです。通信タイプ2は、アプリケーション固有のモジュール（ASM）またはサービス機器へのアプリケーション固有の通信用です。
+-------+
| AAA |<---1---> to AAA server as in fig. 2
request <---4--->|GateWay|
| |<---2---> optionally to ASM/service
+-------+
The numbers in the links denote types of communication.
リンクの数字は、通信の種類を示しています。
Fig. 3 -- AAA Gateway for Legacy AAA Protocols
図3-レガシーAAAプロトコルのAAAゲートウェイ
In a service provider, the Application Specific Module (ASM) and the software providing the service itself may be tightly bound into a single "Service Application". In this case, the interface between them is just a software interface. But the service itself may be provided by equipment external to the ASM, for example, a router in the bandwidth broker application. In this case, the ASM communicates with the service via some protocol. These two possibilities are illustrated in figure 4. In both cases, we have labeled the communication between the ASM and the service as communication type 5, which of course, is service specific.
サービスプロバイダーでは、アプリケーション固有のモジュール（ASM）とサービス自体を提供するソフトウェアが、単一の「サービスアプリケーション」にしっかりとバインドされる場合があります。この場合、それらの間のインターフェースは単なるソフトウェアインターフェイスです。ただし、サービス自体は、ASMの外部の機器、たとえば帯域幅ブローカーアプリケーションのルーターによって提供される場合があります。この場合、ASMは一部のプロトコルを介してサービスと通信します。これらの2つの可能性を図4に示します。どちらの場合も、ASMとサービスの間の通信が通信タイプ5としてラベル付けされています。もちろん、これはサービス固有です。
| |
+--------------|----+ |
| Service 2 | 2
| Application | | |
| +-------------+ | +-------------+
| | Application | | | Application |
| | Specific | | | Specific |
| | Module | | | Module |
| +-------------+ | +-------------+
| | | |
| 5 | 5
| | | |
| +-------------+ | +-------------+
| | Service | | | Service |
| | | | | Equipment |
| +-------------+ | +-------------+
+-------------------+
Fig. 4 -- ASM to Service Interaction (two views)
図4-サービスインタラクションへのASM（2つのビュー）
The generic AAA server modules can use communication type 1 to contact each other to evaluate parts of requests. Figure 5 illustrates a network of generic AAA servers in different administrative domains communicating via communication type 1.
一般的なAAAサーバーモジュールは、通信タイプ1を使用して互いに連絡してリクエストの一部を評価できます。図5は、通信タイプ1を介して通信するさまざまな管理ドメインの一般的なAAAサーバーのネットワークを示しています。
+-----+
o--------| AAA |---->...
/ | |
/ +-----+\
/ | \+----+
/ +-----+ | RP |
/ | ASM | +----+
+--------+ +-----+ / | |
| Client |------| AAA |-------o +-----+
+--------+ | | \
+-----+ \
| +----+ \ +-----+
+-----+ | RP | o-----| AAA |---->...
| ASM | +----+ | |
| | +-----+\
+-----+ | \+----+
+-----+ | RP |
| ASM | +----+
| |
+-----+
The AAA servers use only communication type 1 to communicate. ASM = Application Specific Module RP = Repository
AAAサーバーは、通信タイプ1のみを使用して通信します。ASM =アプリケーション固有のモジュールRP =リポジトリ
Fig. 5 -- Multi-domain Multi-type of Service Architecture
図5-サービスアーキテクチャのマルチドメインマルチタイプ
Some key points of the generic architecture are:
一般的なアーキテクチャの重要なポイントは次のとおりです。
1) The same generic AAA server can function in all three authorization models: agent, pull, and push [2].
1) 同じ一般的なAAAサーバーは、3つの認証モデルすべてで機能する可能性があります：エージェント、プル、プッシュ[2]。
2) The rule based engine knows how to evaluate logical formulas and how to parse AAA requests.
2) ルールベースのエンジンは、論理式を評価する方法とAAA要求を解析する方法を知っています。
3) The Generic AAA server has no knowledge whatsoever about the application specific services so the application specific information it forwards is opaque to it.
3) ジェネリックAAAサーバーには、アプリケーション固有のサービスに関する知識はまったくありません。そのため、アプリケーション固有の情報が転送されます。
4) Communication types 1, 2, and 3 each present their own naming space problems. Solving these problems is fundamental to forwarding AAA messages, locating application specific entities, and locating applicable rules in the rule repositories.
4) 通信タイプ1、2、および3は、それぞれ独自の命名スペースの問題を示しています。これらの問題を解決することは、AAAメッセージを転送し、アプリケーション固有のエンティティを見つけ、ルールリポジトリに適用可能なルールを見つけることに基づいています。
5) A standard AAA protocol for use in communication type 1 should be a peer-to-peer protocol without imposing client and server roles on the communicating entities.
5) 通信タイプ1で使用する標準AAAプロトコルは、通信エンティティにクライアントとサーバーの役割を課すことなく、ピアツーピアプロトコルである必要があります。
6) A standard AAA protocol should allow information units for multiple different services belonging to multiple different applications in multiple different administrative domains to be combined in a single AAA protocol message.
6) 標準のAAAプロトコルでは、複数の異なる管理ドメイン内の複数の異なるアプリケーションに属する複数の異なるサービスの情報ユニットを、単一のAAAプロトコルメッセージに組み合わせることができます。
It is hoped that by using this generic model it will be feasible to design a AAA protocol that is "future proof", in a sense, because much of what we do not think about now can be encoded as application specific information and referenced by policy rules stored in a policy repository. From this model, some generic requirements arise that will require some further study. For example, suppose a new user is told that somewhere on a specific AAA server a certain authorization can be obtained. The user will need a AAA protocol that can:
この汎用モデルを使用することにより、ある意味で「将来の証明」であるAAAプロトコルを設計することが可能になることが期待されています。ポリシーリポジトリに保存されているルール。このモデルから、いくつかの一般的な要件が発生し、さらに調査が必要です。たとえば、新しいユーザーが特定のAAAサーバーのどこかで特定の承認を取得できると言われているとします。ユーザーは、次のことができるAAAプロトコルが必要です。
1) send a query to find out which authorizations can be obtained from a specific server,
1) クエリを送信して、特定のサーバーからどの承認を取得できるかを確認します。
2) provide a mechanism for determining what components must be put in an AAA request for a specific authorization, and
2) 特定の承認のためのAAA要求にどのコンポーネントを入れなければならないかを決定するためのメカニズムを提供し、
3) formulate and transmit the authorization request.
3) 承認リクエストを策定して送信します。
Some areas where further work is particularly needed are in identifying and designing the generic components of a AAA protocol and in determining the basis upon which component forwarding and policy retrieval decisions are made.
さらなる作業が特に必要な領域の一部は、AAAプロトコルの一般的なコンポーネントを特定して設計し、コンポーネントの転送とポリシーの検索決定が行われる基礎を決定することです。
In addition to these areas, there is a need to explore the management of rules in a multi-domain AAA environment because the development and future deployment of a generic multi-domain AAA infrastructure is largely dependent on its manageability. Multi-domain AAA environments housing many rules distributed over several AAA servers quickly become unmanageable if there is not some form of automated rule creation and housekeeping. Organizations that allow their services to be governed by rules, based on some form of commercial contract, require the contract to be implemented with the least possible effort. This can, for example, be achieved in a scalable fashion if the individual user or user organization requesting a service is able to establish the service itself. This kind of interaction requires policy rule establishment between AAA servers belonging to multiple autonomous administrative domains.
これらの分野に加えて、一般的なマルチドメインAAAインフラストラクチャの開発と将来の展開は、その管理可能性に大きく依存しているため、マルチドメインAAA環境でのルールの管理を調査する必要があります。複数のAAAサーバーに配布される多くのルールを収容するマルチドメインAAA環境は、自動化されたルール作成とハウスキーピングが何らかの形でない場合、すぐに管理不能になります。何らかの形の商業契約に基づいて、サービスを規則に支配することを許可する組織は、契約を最小限の努力で実施することを要求しています。たとえば、これは、サービスを要求する個々のユーザーまたはユーザー組織がサービス自体を確立できる場合、スケーラブルな方法で達成できます。この種の相互作用には、複数の自律管理ドメインに属するAAAサーバー間のポリシールール確立が必要です。
In the previous section, we proposed the idea of a generic AAA server with an interface to one or more Application Specific Modules (ASMs). The generic server would handle many common functions including the forwarding of AAA messages between servers in different administrative domains. We envision message transport, hop-by-hop security, and message forwarding as clearly being functions of the generic server. The application specific modules would handle all application specific tasks such as communication with service equipment and access to special purpose databases. Between these two sets of functions is another set of functions that presumably could take place in either the generic server or an ASM or possibly by a collaboration of both. These functions include the evaluation of authorization rules against data that may reside in various places including attributes from the authorization request itself. The more we can push these functions down into the generic server, the more powerful the generic server can be and the simpler the ASMs can be.
前のセクションでは、1つ以上のアプリケーション固有のモジュール（ASM）へのインターフェイスを備えた一般的なAAAサーバーのアイデアを提案しました。一般的なサーバーは、さまざまな管理ドメインのサーバー間のAAAメッセージの転送を含む多くの一般的な関数を処理します。メッセージトランスポート、ホップバイホップセキュリティ、およびメッセージ転送は、一般的なサーバーの関数であると想定しています。アプリケーション固有のモジュールは、サービス機器との通信や特別な目的データベースへのアクセスなど、すべてのアプリケーション固有のタスクを処理します。これらの2つの関数セットの間には、一般的なサーバーまたはASMで、またはおそらく両方のコラボレーションによって発生する可能性がある別の関数セットがあります。これらの機能には、承認要求自体からの属性を含むさまざまな場所に存在する可能性のあるデータに対する承認ルールの評価が含まれます。これらの関数をジェネリックサーバーに押し込むことができるほど、一般的なサーバーはより強力になり、ASMがより簡単になります。
One way of organizing the different functions mentioned above would be to assign them to a layered hierarchy. In fact, we have found the layer paradigm to be a useful one in understanding AAA functionality. This section explores the use of a layered hierarchy consisting of the following AAA layers as a way of organizing the AAA functions:
上記のさまざまな機能を整理する1つの方法は、それらを階層化された階層に割り当てることです。実際、レイヤーパラダイムは、AAA機能を理解する上で有用なものであることがわかりました。このセクションでは、AAA関数を整理する方法として、次のAAAレイヤーで構成される層状階層の使用について説明します。
Application Specific Service Layer Presentation Service Layer Transaction/Session Management Service Layer Reliable/Secure Transport Service Layer
アプリケーション固有のサービスレイヤープレゼンテーションサービスレイヤートランザクション/セッション管理サービスレイヤー信頼できる/安全な輸送サービスレイヤー
Nevertheless, the interface between the generic AAA server and the ASMs proposed in the previous section may be more complex than a simple layered model would allow. Even the division of functionality proposed in this section goes beyond a strict understanding of layering. Therefore this paper can probably best be understood as the beginnings of a work to understand and organize the common functionality required for a general purpose AAA infrastructure rather than as a mature reference model for the creation of AAA protocols.
それにもかかわらず、一般的なAAAサーバーと前のセクションで提案されているASMとの間のインターフェイスは、単純な層状モデルが許可するよりも複雑な場合があります。このセクションで提案されている機能部門でさえ、レイヤー化の厳格な理解を超えています。したがって、この論文は、おそらく、AAAプロトコルの作成のための成熟した参照モデルとしてではなく、汎用AAAインフラストラクチャに必要な共通の機能を理解および整理する作業の始まりとして最もよく理解できます。
In our view of AAA services modeled as a hierarchy of service layers, there is a set of distributed processes at each service layer that cooperate and are responsible for implementing that service layer's functions. These processes communicate with each other using a protocol specialized to carry out the functions and responsibilities assigned to their service layer. The protocol at service layer n communicates to its peers by depending on the services available to it from service layer n-1. The service layer n also has a protocol end point address space, through which the peer processes at service layer n can send messages to each other. Together, these AAA service layers can be assembled into an AAA protocol stack.
サービスレイヤーの階層としてモデル化されたAAAサービスの見解には、各サービスレイヤーに分散プロセスのセットがあり、そのサービスレイヤーの機能を実装する責任があります。これらのプロセスは、サービスレイヤーに割り当てられた機能と責任を実行するために専門のプロトコルを使用して相互に通信します。Service Layer Nのプロトコルは、サービスレイヤーN-1から利用可能なサービスに応じて、ピアに通信します。サービスレイヤーnには、プロトコルエンドポイントアドレス空間もあり、それを通じてサービスレイヤーnでのピアプロセスが互いにメッセージを送信できます。一緒に、これらのAAAサービスレイヤーは、AAAプロトコルスタックに組み立てることができます。
The advantage of this approach is that there is not just one monolithic "AAA protocol". Instead there is a suite of protocols, and each one is optimized to solve the problems found at its layer of the AAA protocol stack hierarchy.
このアプローチの利点は、1つのモノリシックな「AAAプロトコル」だけではないことです。代わりに、一連のプロトコルがあり、それぞれがAAAプロトコルスタック階層の層で見つかった問題を解決するために最適化されています。
This approach realizes several key benefits:
このアプローチはいくつかの重要な利点を実現します。
- The protocol used at any particular layer in the protocol stack can be substituted for another functionally equivalent protocol without disrupting the services in adjacent layers.
- プロトコルスタック内の特定のレイヤーで使用されるプロトコルは、隣接する層のサービスを破壊することなく、別の機能的に同等のプロトコルに置き換えることができます。
- Requirements in one layer may be met without impact on protocols operating in other layers. For example, local security requirements may dictate the substitution of stronger or weaker "reliable secure transport" layer security algorithms or protocols. These can be introduced with no change or awareness of the substitution by the layers above the Reliable/Secure Transport layer.
- 1つのレイヤーの要件は、他のレイヤーで動作するプロトコルに影響を与えることなく満たされる場合があります。たとえば、ローカルセキュリティ要件は、より強力または弱い「信頼性の高い安全な輸送」層のセキュリティアルゴリズムまたはプロトコルの代替を決定する場合があります。これらは、信頼できる/安全な輸送層の上の層による置換の変更や認識なしで導入できます。
- The protocol used for a given layer is simpler because it is focused on a specific narrow problem that is assigned to its service layer. In particular, it should be feasible to leverage existing protocol designs for some aspects of this protocol stack (e.g. CORBA GIOP/CDR for the presentation layer).
- 特定のレイヤーに使用されるプロトコルは、サービスレイヤーに割り当てられる特定の狭い問題に焦点を合わせているため、より簡単です。特に、このプロトコルスタックのいくつかの側面に既存のプロトコル設計を活用することが可能です（例：プレゼンテーションレイヤーのCorba Giop/CDR）。
- A legacy AAA protocol message (e.g. a RADIUS message) can be encapsulated within the protocol message(s) of a lower layer protocol, preserving the investment of a Service Provider or User Home Organization in their existing AAA infrastructure.
- レガシーAAAプロトコルメッセージ（半径メッセージなど）は、下層プロトコルのプロトコルメッセージ内にカプセル化でき、既存のAAAインフラストラクチャにおけるサービスプロバイダーまたはユーザーホーム組織の投資を維持できます。
- At each service layer, a suite of alternatives can be designed, and the service layer above it can choose which alternative makes sense for a given application. However, it should be a primary goal of the AAA protocol standardization effort to specify one mandatory to implement protocol at the AAA Transaction/Session Management (AAA-TSM) service layer (see section 3.4).
- 各サービスレイヤーでは、一連の代替案を設計でき、その上のサービスレイヤーは、特定のアプリケーションにとってどの代替手段が理にかなっているかを選択できます。ただし、AAAトランザクション/セッション管理（AAA-TSM）サービスレイヤーにプロトコルを実装するために必須の1つを指定するためのAAAプロトコル標準化の取り組みの主要な目標である必要があります（セクション3.4を参照）。
At each layer of a layered architecture, a number of elements need to be defined. These elements are discussed in the following sections.
層状アーキテクチャの各層で、多くの要素を定義する必要があります。これらの要素については、次のセクションで説明します。
The service layer n is assumed to present a program interface through which its adjacent service layer n+1 can access its services. The types of abstract program service primitives and associated parameters exchanged across the boundary between these service layers must be specified.
サービスレイヤーNは、隣接するサービスレイヤーn 1がサービスにアクセスできるプログラムインターフェイスを提示すると想定されています。これらのサービスレイヤー間の境界を越えて交換される抽象プログラムサービスプリミティブと関連するパラメーターの種類を指定する必要があります。
Each service layer is treated as a set of cooperating processes distributed across multiple computing systems. The service layer must manage an end point name space that identifies these peer processes. The conventions by which a service layer assigns a unique end point name to each such peer process must be specified.
各サービスレイヤーは、複数のコンピューティングシステムに分散された一連の協力プロセスとして扱われます。サービスレイヤーは、これらのピアプロセスを識別するエンドポイント名スペースを管理する必要があります。サービスレイヤーがそのような各ピアプロセスに一意のエンドポイント名を割り当てる規則を指定する必要があります。
Along with defining an end point name space, a service layer must also specify how its peers:
エンドポイント名スペースの定義に加えて、サービスレイヤーはピアを指定する必要があります。
- announce their presence and availability,
- 彼らの存在と可用性を発表し、
- discover one another when they first begin operation, and
- 彼らが最初に操作を開始したらお互いを発見し、
- detect loss of connectivity or service withdrawal.
- 接続またはサービスの引き出しの損失を検出します。
It is also necessary to specify what mechanisms, if any, exist to resolve a set of service layer specific search attributes into one or more peer end point names that match the search criteria.
また、検索基準に一致する1つ以上のピアエンドポイント名に、サービスレイヤー固有の検索属性のセットを解決するために、どのメカニズムが存在するかを指定する必要があります。
Once an end point has established its initial contact with another peer, it must decide what authentication policy to adapt. It can trust whatever authentication was done on its behalf by a lower service layer or, through a pre-provisioning process, implicitly trust the peer, or else go through an authentication process with its peer. The supported mechanisms for establishing a service layer's end point trust relationships must be specified.
エンドポイントが別のピアとの最初の接触を確立したら、適応するための認証ポリシーを決定する必要があります。より低いサービスレイヤーによって、または事前プロビジョニングプロセスを通じて、ピアを暗黙的に信頼したり、ピアとともに認証プロセスを経ていることで、その認証が行われた認証を信頼することができます。サービスレイヤーのエンドポイント信頼関係を確立するためのサポートされているメカニズムを指定する必要があります。
To the extent that a service layer's internal states are externally visible, the layer's behavior in terms of a Finite State Machine (FSM) should be specified. Events that can drive the FSM state transitions may include:
サービスレイヤーの内部状態が外部から見える限り、有限状態マシン（FSM）に関するレイヤーの動作を指定する必要があります。FSM状態の移行を促進できるイベントには、以下が含まれます。
- service layer n+1 interface primitive requests
- サービスレイヤーn 1インターフェイスプリミティブリクエスト
- protocol data unit arrivals from peer service layer n end points received through the layer n-1 access point
- プロトコルデータユニットピアサービスレイヤーからの到着nレイヤーn-1アクセスポイントを介して受信したエンドポイント
- service layer n-1 interface primitives (e.g. call backs or interrupts)
- サービスレイヤーN-1インターフェイスプリミティブ（例：コールバックまたは割り込み）
- timer expirations
- タイマーの満了
Each service layer defines a lexicon of protocol data units (PDUs) that communicate between the layer's peer processes the information that controls and/or monitors that service layer's distributed state and allows the service processes of that layer to perform their functions. Embedded in the PDUs of each layer are the PDUs of the higher layers which depend on its services. The PDUs of each service layer must be specified.
各サービスレイヤーは、レイヤーのピア間で通信するプロトコルデータユニット（PDU）のレキシコンを定義します。これは、サービスレイヤーの分散状態を制御および/または監視する情報を定義し、そのレイヤーのサービスプロセスが機能を実行できるようにします。各レイヤーのPDUに埋め込まれているのは、そのサービスに依存する高層のPDUです。各サービスレイヤーのPDUを指定する必要があります。
AAA applications have almost unlimited diversity, but imposing some constraints and commonality is required for them to participate in this generic AAA architectural framework. To satisfy these constraints, participating AAA applications would derive their application specific program logic from a standardized "Authorization Server" abstract base object class. They would also support an "Authorized Session" object class. An Authorization Session object instance represents an approved authorization request that has a long-lived allocation of services or resources. The generic AAA architecture could be extended to include other abstract base object classes in the future (e.g. Authorization Reservation, Authentication Server, etc.). How to implement the derived Authorization Server class's public methods for a given problem domain is entirely up to the application. One technique might be to place a software "wrapper" around an existing embedded application specific service to adapt it to the standardized Authorization Server object paradigm. The major Authorization Server class methods are:
AAAアプリケーションにはほとんど無制限の多様性がありますが、この一般的なAAAアーキテクチャフレームワークに参加するには、いくつかの制約と共通性を課す必要があります。これらの制約を満たすために、参加するAAAアプリケーションは、標準化された「認証サーバー」抽象的なベースオブジェクトクラスからアプリケーション固有のプログラムロジックを導き出します。また、「認定セッション」オブジェクトクラスもサポートします。承認セッションオブジェクトインスタンスは、サービスまたはリソースの長期的な割り当てがある承認された承認要求を表します。一般的なAAAアーキテクチャは、将来の他の抽象的なベースオブジェクトクラス（承認予約、認証サーバーなど）を含めるように拡張できます。特定の問題ドメインに対する派生承認サーバークラスのパブリックメソッドを実装する方法は、完全にアプリケーション次第です。1つの手法は、標準化された承認サーバーオブジェクトパラダイムに適応するために、既存の組み込みアプリケーション固有のサービスの周りにソフトウェア「ラッパー」を配置することです。主要な承認サーバーのクラスメソッドは次のとおりです。
- Publish an advertisement that describes the Authorization Server's service attributes and its application specific service layer end point address. Once the Authorization Server has registered, peer processes can discover its presence or send messages addressed to it.
- Authorization Serverのサービス属性とそのアプリケーション固有のサービスレイヤーエンドポイントアドレスを説明する広告を公開します。Authorization Serverが登録されると、ピアプロセスはその存在を発見したり、アドレス指定されたメッセージを送信したりできます。
- Application Specific Authorization Decision Function (AS-ADF) method takes a User's application specific authorization request and returns a decision of approve, deny, or conditionally approve with referral to another stakeholder. In the latter case, the application may create a reservation for the requested services or resources. This method represents the "condition" side of a policy rule's condition/action pair.
- アプリケーション固有の承認決定機能（AS-ADF）メソッドユーザーのアプリケーション固有の承認要求を受け取り、別の利害関係者への紹介で承認、拒否、または条件付き承認の決定を返します。後者の場合、アプリケーションは要求されたサービスまたはリソースの予約を作成する場合があります。この方法は、ポリシールールの条件/アクションペアの「条件」側を表します。
- Commit a service or set of resources to a previously conditionally approved authorization decision. For those authorization requests that have a long-term lifecycle (as opposed to being transactions), this method mobilizes a reservation into an Authorized Session object instance. This method represents the "action" side of a policy rule's condition/action pair.
- 以前に条件付きで承認された許可決定にサービスまたはリソースのセットをコミットします。（トランザクションであるのではなく）長期のライフサイクルを持つ許可リクエストのために、この方法は承認されたセッションオブジェクトインスタンスへの予約を動員します。この方法は、ポリシールールの条件/アクションペアの「アクション」側を表します。
- Cancel a previously conditionally approved Authorization request. This method releases any associated reservations for services or resources.
- 以前に条件付きで承認された承認要求をキャンセルします。この方法は、サービスまたはリソースの関連する予約をリリースします。
- Withdraw the Authorization Server's service advertisement.
- Authorization Serverのサービス広告を撤回します。
A key motivation for structuring an AAA application as an Authorization Server object instance is to separate the generic authorization decision logic from the application-specific authorization decision logic. In many cases, the application can be divorced from the AAA problem altogether, and its AAA responsibility can be assigned to an external rules based generic AAA Server. (The idea is similar to that of a trust management policy server as defined in [5].) This would facilitate a security administrator deploying AAA policy in a central repository. The AAA policy is applied consistently across all users of the applications, resources, and services controlled by the AAA server. However, it is recognized that for many problem domains, there are unique rules intrinsic to the application. In these cases, the generic AAA Server must refer the User's authorization request to the relevant Application Specific Module.
AAAアプリケーションを承認サーバーオブジェクトインスタンスとして構築するための重要な動機は、一般的な認証決定ロジックをアプリケーション固有の認証決定ロジックから分離することです。多くの場合、アプリケーションはAAA問題から完全に離婚することができ、そのAAAの責任は、外部ルールに基づく汎用AAAサーバーに割り当てることができます。（このアイデアは、[5]で定義されている信頼管理ポリシーサーバーのアイデアに似ています。）これにより、中央リポジトリにAAAポリシーを展開するセキュリティ管理者が容易になります。AAAポリシーは、AAAサーバーによって制御されるアプリケーション、リソース、およびサービスのすべてのユーザーに一貫して適用されます。ただし、多くの問題ドメインでは、アプリケーションに固有の一意のルールがあることが認識されています。これらの場合、一般的なAAAサーバーは、ユーザーの承認要求を関連するアプリケーション固有のモジュールに参照する必要があります。
The presentation service layer solves the data representation problems that are encountered when communicating peers exchange complex data structures or objects between their heterogeneous computing systems. The goal is to transfer semantically equivalent application layer data structures regardless of the local machine architecture, operating system, compiler, or other potential inter-system differences.
プレゼンテーションサービスレイヤーは、ピアが複雑なデータ構造または異種コンピューティングシステム間でオブジェクトを交換するときに発生するデータ表現の問題を解決します。目標は、ローカルマシンアーキテクチャ、オペレーティングシステム、コンパイラ、またはその他の潜在的なシステム間の違いに関係なく、意味的に同等のアプリケーションレイヤーデータ構造を転送することです。
One way to better understand the role of the presentation layer is to evaluate an existing example. The Generic Inter-ORB Protocol (GIOP) and its Common Data Representation (CDR) is a presentation service layer protocol developed by the Object Management Group (OMG) industry consortium. GIOP is one component within the Common Object Request Broker Architecture (CORBA). Peer Object Request Brokers (ORB) executing on heterogeneous systems use GIOP to invoke remote CORBA object interface methods. GIOP encodes an object method's input and output parameters in the Common Data Representation (CDR). While there are other presentation service layer protocols in the industry, GIOP in combination with CDR represents a mature, comprehensive solution that exhibits many of the presentation service layer requirements that are applicable within the AAA protocol model.
プレゼンテーションレイヤーの役割をよりよく理解する1つの方法は、既存の例を評価することです。一般的なORB間プロトコル（GIOP）とその共通データ表現（CDR）は、オブジェクト管理グループ（OMG）業界コンソーシアムによって開発されたプレゼンテーションサービスレイヤープロトコルです。GIOPは、Common Object Request Broker Architecture（CORBA）内の1つのコンポーネントです。異種システムで実行するピアオブジェクト要求ブローカー（ORB）は、GIOPを使用してリモートCorbaオブジェクトインターフェイスメソッドを呼び出します。GIOPは、一般的なデータ表現（CDR）にオブジェクトメソッドの入力パラメーターと出力パラメーターをエンコードします。業界には他のプレゼンテーションサービスレイヤープロトコルがありますが、CDRと組み合わせたGIOPは、AAAプロトコルモデル内で適用されるプレゼンテーションサービスレイヤー要件の多くを示す成熟した包括的なソリューションを表しています。
In the context of Internet access AAA protocols, RADIUS and its successors use the Attribute Value Pair (AVP) paradigm as the presentation service layer encoding scheme. While such an approach is versatile, it is also prone to becoming splintered into many ad hoc and vendor specific dialects. There is no structure imposed or method to negotiate the constraints on which AVPs are combined and interpreted for a given conversation in a consistent way across AAA protocol implementations or problem domains. At run-time, it can be hard for the communicating peers to negotiate to a common inter-operable set of AVPs.
インターネットアクセスAAAプロトコルのコンテキストでは、RADIUSとその後継者は、属性値ペア（AVP）パラダイムをプレゼンテーションサービスレイヤーエンコードスキームとして使用します。このようなアプローチは汎用性がありますが、多くのアドホックとベンダー固有の方言に分裂する傾向があります。AAAプロトコルの実装または問題ドメイン全体で一貫した方法で、特定の会話のためにAVPが組み合わされて解釈される制約を交渉する構造や方法はありません。実行時には、通信仲間が共通の操作可能なAVPのセットと交渉するのは難しい場合があります。
To avoid this pitfall, a primary presentation service layer responsibility is the ability to let peers negotiate from a base Authorization Server object class towards a commonly understood derived Authorization Server object class that both presentation service layer peers have implemented for their application specific problem domain. This negotiation implies a requirement for a globally registered and maintained presentation service layer hierarchy of Authorization Server object class names.
この落とし穴を回避するために、主要なプレゼンテーションサービスレイヤーの責任は、ベース認証サーバーオブジェクトクラスから、アプリケーション固有の問題ドメインのために両方のプレゼンテーションサービスレイヤーピアが実装した一般的に理解されている派生承認サーバーオブジェクトクラスに向けて交渉できることです。このネゴシエーションは、グローバルに登録および維持されているプレゼンテーションサービスレイヤー承認サーバーオブジェクトクラス名の階層の要件を意味します。
The AAA Transaction/Session Management (AAA-TSM) service layer is a distributed set of AAA Servers, which typically reside in different administrative domains. Collectively they are responsible for the following three services: Authentication -- Execute the procedure(s) needed to confirm the identity of the other parties with which the AAA TSM entity has a trust relationship.
AAAトランザクション/セッション管理（AAA-TSM）サービスレイヤーは、通常、異なる管理ドメインに存在するAAAサーバーの分散セットです。総称して、次の3つのサービスに責任を負います。認証 - AAA TSMエンティティが信頼関係を持っている他の関係者の身元を確認するために必要な手順を実行します。
Authorization -- Make an authorization decision to grant or deny a User's request for services or resources. The generic rules based policy engine described earlier in this document executes the authorization decision function. When the User's request is instantaneous and transient, then its authorization approval is treated as an ephemeral transaction. If the authorization approval implies a sustained consumption of a service or resources, then the request is transformed into an Authorized Session. For the duration of the Authorized Session's lifetime:
承認 - ユーザーのサービスまたはリソースの要求を許可または拒否するための許可決定を下します。このドキュメントで前述の一般的なルールベースのポリシーエンジンは、認証決定機能を実行します。ユーザーの要求が瞬時で一時的な場合、その承認承認は一時的な取引として扱われます。承認の承認がサービスまたはリソースの持続的な消費を意味する場合、リクエストは承認されたセッションに変換されます。認定セッションの寿命の期間中：
- its state may be queried and reported, or
- その状態は質問および報告される可能性があります
- it may be canceled before service is completed, or
- サービスが完了する前にキャンセルされる可能性があります。
- the service being delivered may be modified to operate under new parameters and conditions, or
- 配信されるサービスは、新しいパラメーターと条件の下で動作するように変更される場合があります。
- the service may complete on its own accord.
- サービスはそれ自体で完了する場合があります。
In each of these cases, the AAA-TSM service layer must synchronize the Authorized Session's distributed state across all of those AAA Servers which are implementing that specific Authorized Session.
これらの各ケースでは、AAA-TSMサービスレイヤーは、その特定の承認されたセッションを実装しているすべてのAAAサーバーで、認定セッションの分散状態を同期する必要があります。
Accounting -- Generate any relevant accounting information regarding the authorization decision and the associated Authorized Session (if any) that represents the ongoing consumption of those services or resources.
会計 - それらのサービスまたはリソースの継続的な消費を表す認可決定と、関連する認定セッション（もしあれば）に関する関連する会計情報を生成します。
The peer AAA servers and their AAA-TSM end points exchange AAA-TSM messages to realize these AAA functions. A central AAA-TSM concept is that there is a set of one or more AAA Server stakeholders who are solicited to approve/disapprove a User request for application layer services. The AAA-TSM service layer routes the User's request from one stakeholder to the next, accumulating the requisite approvals until they have all been asked to make an authorization decision.
ピアAAAサーバーとそのAAA-TSMエンドポイントは、これらのAAA機能を実現するためにAAA-TSMメッセージを交換します。中央AAA-TSMの概念は、アプリケーションレイヤーサービスのユーザー要求を承認/不承認にするように勧誘された1つ以上のAAAサーバーの利害関係者のセットがあることです。AAA-TSMサービスレイヤーは、ユーザーの要求をある利害関係者から次の利害関係者にルーティングし、すべてが認可決定を下すように求められるまで、必要な承認を蓄積します。
The AAA Servers may also do User authentication (or re-authentication) as part of this approval process. The overall flow of the routing from one stakeholder to another may take the form of the "push", "pull", or "agent" authorization models developed in [2]. However, in principle, it is feasible to have an arbitrary routing path of an AAA-TSM authorization request among stakeholders. Once the final approval is received, the AAA-TSM service layer commits the requested service by notifying all of those stakeholders that require a confirmation (i.e. turn on a pending reservation and do a transaction commit). Alternatively, any stakeholder among those on the consent list can veto the authorization request. In that case, all stakeholders who previously approved the request and had asked for a confirmation are told that the request has been denied (i.e., cancel reservation and do a transaction rollback).
AAAサーバーは、この承認プロセスの一部としてユーザー認証（または再認証）を行うこともできます。ある利害関係者から別の利害関係者へのルーティングの全体的な流れは、[2]で開発された「プッシュ」、「プル」、または「エージェント」認証モデルの形をとることができます。ただし、原則として、利害関係者の間でAAA-TSM承認要求の任意のルーティングパスを持つことが可能です。最終承認が受け取られると、AAA-TSMサービスレイヤーは、確認を必要とするすべての利害関係者に通知することにより、要求されたサービスをコミットします（つまり、保留中の予約をオンにして取引コミットを行う）。あるいは、同意リストに載っている人の中の利害関係者は、承認要求を拒否できます。その場合、以前にリクエストを承認し、確認を求めていたすべての利害関係者は、リクエストが拒否されたことを伝えられます（つまり、予約をキャンセルしてトランザクションロールバックを実行します）。
The AAA-TSM authorization request payload must carry its own "Context State", such that when an AAA server receives it, there is sufficient information that it is essentially self-contained. Embedding the Context State within the AAA-TSM message provides two benefits. First, the message can be immediately processed with respect to the AAA Server's local policy, and this minimizes or altogether avoids the need for the AAA Server to exchange additional AAA-TSM messages with its peers to complete its piece of the overall authorization decision. The other benefit is that the AAA Server minimizes the amount of state information resources that it commits to a user's pending request until it is fully approved. This helps protect against denial of service attacks.
AAA-TSM認証リクエストのペイロードは、独自の「コンテキスト状態」を運ぶ必要があります。これにより、AAAサーバーがそれを受信すると、本質的に自己完結型であるという十分な情報があります。AAA-TSMメッセージ内にコンテキスト状態を埋め込むと、2つの利点が提供されます。まず、メッセージはAAAサーバーのローカルポリシーに関してすぐに処理できます。これにより、AAAサーバーが追加のAAA-TSMメッセージをピアと交換して、全体的な承認決定の一部を完了する必要性を最小限に抑えるか、完全に回避できます。もう1つの利点は、AAAサーバーが完全に承認されるまでユーザーの保留中の要求にコミットする州の情報リソースの量を最小化することです。これは、サービス拒否攻撃から保護するのに役立ちます。
One can envision many possible message elements that could be part of the Context State carried within an AAA-TSM request message:
AAA-TSMリクエストメッセージ内で運ばれるコンテキスト状態の一部である可能性のある多くの可能なメッセージ要素を想像できます。
- AAA-TSM session identifier, a unique handle representing this authorization request. All AAA servers who participate in a request's approval process and its subsequent monitoring throughout its Session lifetime refer to this handle.
- AAA-TSMセッション識別子、この承認要求を表す一意のハンドル。リクエストの承認プロセスとその後の監視に参加するすべてのAAAサーバーは、セッションの生涯を通じてこのハンドルを参照しています。
- permission lists stating which AAA Servers are allowed to modify which parts of the message.
- 許可リストでは、どのAAAサーバーがメッセージのどの部分を変更できるかを記載しています。
- User's authorization request, encoded as a presentation layer PDU.
- プレゼンテーションレイヤーPDUとしてエンコードされたユーザーの承認要求。
- User authentication information, (e.g. an X.509 public key certificate).
- ユーザー認証情報（X.509公開証明書など）。
- User credentials information, or else a pointer to where that information can be found by an AAA server. An example of such credentials would be an X.509 attributes certificate.
- ユーザーの資格情報、またはAAAサーバーがその情報を見つけることができる場所へのポインター。このような資格情報の例は、X.509属性証明書です。
- the list of AAA Server stakeholders who have yet to be visited to gain full approval of the User's authorization request. Each element in that list contains a presentation layer message encoding how the user authorization request should be evaluated by its application specific Authorization Decision Function (ADF).
- ユーザーの承認要求の完全な承認を得るためにまだ訪問されていないAAAサーバーの利害関係者のリスト。そのリストの各要素には、アプリケーション固有の認証決定機能（ADF）によってユーザー認証要求を評価する方法をエンコードするプレゼンテーションレイヤーメッセージが含まれています。
- the current position in the list of AAA Server stakeholders to be visited.
- 訪問するAAAサーバーの利害関係者のリストの現在の位置。
- a list of those AAA servers which have already conditionally approved the User's authorization request, but which have predicated their approval on the request also completing its approval from those stakeholders who have not yet seen the request. Each element in the list has a digital signature or comparable mechanism by which their approval can be subsequently verified.
- ユーザーの承認要求をすでに条件付きで承認したが、リクエストに対する承認を前提としているAAAサーバーのリストも、リクエストをまだ見ていない利害関係者からの承認を完了しました。リスト内の各要素には、デジタル署名または同等のメカニズムがあり、その後承認を検証できます。
- an expiration time stamp, expressed in a universally understood time reference, which sets a lifetime limit on the AAA-TSM message's validity. This offers some replay attack protection, and inhibits messages from circulating indefinitely seeking the completion of a request's approval.
- AAA-TSMメッセージの有効性に寿命の制限を設定する、普遍的に理解された時間参照で表される有効期限のあるタイムスタンプ。これにより、いくつかのリプレイ攻撃保護が提供され、リクエストの承認の完了を無期限に求めて循環することをメッセージが阻害します。
- a message payload modification audit trail, tracing which parties introduced changes into the User's authorization request terms and conditions.
- メッセージペイロード修正監査トレイル、当事者がユーザーの承認要求条件に変更を導入したトレース。
- an AAA-TSM message integrity check, computed across the whole message rather than its individual elements, and signed by the most recent AAA-TSM layer end point process to modify the AAA-TSM message before its transmission to its AAA-TSM peer. This function may be delegated to the underlying Reliable Secure Transport layer connection to that destination peer.
- AAA-TSMメッセージの整合性チェックは、個々の要素ではなくメッセージ全体にわたって計算され、AAA-TSMピアに送信する前にAAA-TSMメッセージを変更するために最新のAAA-TSMレイヤーエンドポイントプロセスによって署名されます。この機能は、その目的地のピアへの基礎となる信頼できる安全な輸送層接続に委任される場合があります。
The AAA-TSM service layer and its adjacent presentation service layer communicate across their boundary through a set of program interface primitives. A key design goal is to keep these primitives the same regardless of the higher level AAA application, analogous to a callable "plug-in". The two service layers are responsible for coordinating their state information. This responsibility includes all of the pending Authorization requests and the Authorization Sessions that they are both controlling and monitoring. The initial contact between these two layers is through an abstract object that is called an AAA-TSM Service Access Point (SAP). A particular service instance between these two layers is realized in an abstract object that is called an Authorized Session. The presentation service layer invokes AAA-TSM interface primitives against an AAA-TSM SAP.
AAA-TSMサービスレイヤーとその隣接するプレゼンテーションサービスレイヤーは、一連のプログラムインターフェイスプリミティブを介して境界を越えて通信します。重要な設計目標は、これらのプリミティブを、より高いレベルのAAAアプリケーションに関係なく、呼び出し可能な「プラグイン」に類似していることです。2つのサービスレイヤーは、州の情報を調整する責任があります。この責任には、保留中のすべての承認要求と、それらが支配と監視の両方である許可セッションが含まれます。これら2つのレイヤー間の最初の接触は、AAA-TSMサービスアクセスポイント（SAP）と呼ばれる抽象オブジェクトを使用しています。これら2つのレイヤー間の特定のサービスインスタンスは、承認されたセッションと呼ばれる抽象的なオブジェクトで実現されます。プレゼンテーションサービスレイヤーは、AAA-TSM SAPに対してAAA-TSMインターフェイスプリミティブを呼び出します。
The AAA-TSM service layer interface primitives can be broadly characterized as follows:
AAA-TSMサービスレイヤーインターフェイスプリミティブは、次のように広く特徴付けられます。
- Register a presentation end point address identifier and its associated set of attributes to a service access point.
- プレゼンテーションエンドポイントアドレス識別子とその関連する属性セットをサービスアクセスポイントに登録します。
- Send a presentation layer message to a specified destination presentation layer peer end point address.
- 指定された宛先プレゼンテーションレイヤーピアエンドポイントアドレスにプレゼンテーションレイヤーメッセージを送信します。
- Receive a presentation layer message from another presentation layer end point address. A receive operation may select a specific originating presentation layer end point address from which the message is expected, or receive a message from any presentation layer peer.
- 別のプレゼンテーションレイヤーエンドポイントアドレスからプレゼンテーションレイヤーメッセージを受信します。受信操作は、メッセージが予想される特定の発信プレゼンテーションレイヤーエンドポイントアドレスを選択するか、プレゼンテーションレイヤーピアからメッセージを受信する場合があります。
- The AAA-TSM service layer calls an application specific authorization decision function, which returns a condition code expressing an approval, denial, or partially approves with a referral to another AAA Server.
- AAA-TSMサービスレイヤーは、別のAAAサーバーへの紹介で承認、拒否、または部分的に承認を表す条件コードを返すアプリケーション固有の認証決定機能を呼び出します。
- AAA-TSM service layer tells the presentation layer to commit an earlier partially approved authorization request.
- AAA-TSMサービスレイヤーは、プレゼンテーションレイヤーに、以前の部分的に承認された承認要求をコミットするように指示します。
- Cancel an earlier partially approved authorization request (i.e. rollback).
- 以前の部分的に承認された承認要求（つまり、ロールバック）をキャンセルします。
- The presentation service layer notifies the AAA-TSM service layer that it has terminated an in-progress Authorized Session.
- プレゼンテーションサービスレイヤーは、AAA-TSMサービスレイヤーに、進行中の認定セッションを終了したことを通知します。
- AAA-TSM service layer notifies the presentation service layer that another presentation service layer peer has terminated an Authorized Session.
- AAA-TSMサービスレイヤーは、プレゼンテーションサービスレイヤーに、別のプレゼンテーションサービスレイヤーピアが認定セッションを終了したことを通知します。
- Un-register a presentation service layer end point address.
- プレゼンテーションサービスレイヤーエンドポイントアドレスを登録しません。
The AAA-TSM service layer end point name space is the N-tuple formed by concatenating the following components:
AAA-TSMサービスレイヤーエンドポイント名スペースは、次のコンポーネントを連結することにより形成されるN-Tupleです。
- AAA Server's Reliable/Secure Transport layer end point address
- AAAサーバーの信頼できる/安全なトランスポートレイヤーエンドポイントアドレス
- AAA-TSM authorization request serial number, a unique durable unsigned integer generated by the AAA Server who first receives the User's authorization request.
- AAA-TSM認証リクエストシリアル番号、最初にユーザーの承認リクエストを受信したAAAサーバーによって生成された一意の耐久性のない署名の整数です。
Some AAA applications may require that each assigned AAA-TSM transaction serial number be stored in persistent storage, and require that it be recoverable across AAA Server system re-boots. The serial number generation algorithm must be guaranteed unique even if the AAA Server does a re-boot.
一部のAAAアプリケーションでは、割り当てられた各AAA-TSMトランザクションシリアル番号を永続的なストレージに保存する必要があり、AAAサーバーシステムの再起動全体で回復可能である必要があります。AAAサーバーが再起動を行う場合でも、シリアル番号生成アルゴリズムは一意に保証する必要があります。
The layering paradigm makes it possible to use the most appropriate syntax for each application for encoding the Application Specific Information units of that application. This encoding would take place at the presentation layer. Similarly the application layer can recognize the semantics specific to each application. Figure 6 illustrates some possible AAA protocol stacks.
階層化パラダイムにより、各アプリケーションのアプリケーション固有の情報単位をエンコードするために、各アプリケーションに最も適切な構文を使用することができます。このエンコードは、プレゼンテーションレイヤーで行われます。同様に、アプリケーション層は、各アプリケーションに固有のセマンティクスを認識できます。図6は、可能なAAAプロトコルスタックをいくつか示しています。
+------------++------------++-----------++-----------++----------+
| || Application|| E-Commerce|| Bandwidth || Roaming &|
| AAA || specific || Internet || Broker || mobile IP|
| Application||object class|| Open ||cross-admin|| remote |
| Service || interface || Trading || domain || access |
| Layer ||specified in|| Protocol || COPS || AVP |
| || CORBA IDL || (IOTP) || extensions|| lexicons |
+------------++------------++-----------++-----------++----------+
| || CORBA ||Extensible || Common || DIAMETER |
|Presentation|| Generic || Markup || Open || or |
| Service || Inter-ORB || Language || Policy || RADIUS |
| Layer || Protocol || (XML) ||Specificatn||Attribute |
| || (GIOP) || || (COPS) ||Value/Pair|
+------------++------------++-----------++-----------++----------+
| AAA-TSM Service Layer Application Program Interface (API) |
+----------------------------------------------------------------+
| AAA Transaction/Session Management (AAA-TSM) Service Layer |
+----------------------------------------------------------------+
| Reliable Secure Transport Layer |
+----------------------------------------------------------------+
Fig. 6 -- Possible AAA Protocol Stacks
図6-可能なAAAプロトコルスタック
Security considerations for the framework on which the work described in this memo is based are discussed in [2]. Security requirements for authorization are listed in section 2.2 of [3].
このメモで説明されている作業が基づいているフレームワークのセキュリティ上の考慮事項[2]で説明されています。許可のセキュリティ要件は、[3]のセクション2.2にリストされています。
This memo identifies a basic set of AAA functions that are general in nature and common to many different AAA applications. We propose that a standard set of security mechanisms should be defined as part of a base AAA protocol which would include such things as public key encryption and digital signatures that could be applied to individual information units within an AAA message. Security with this granularity is needed to meet the end-to-end security requirement specified in section 2.2.7 of [3] because a single AAA message may contain multiple information units each generated by AAA servers from different administrative domains and destined to AAA servers in different domains.
このメモは、本質的に一般的であり、多くの異なるAAAアプリケーションに共通するAAA関数の基本セットを識別します。セキュリティメカニズムの標準セットは、AAAメッセージ内の個々の情報ユニットに適用できる公開キーの暗号化やデジタル署名などのものを含むベースAAAプロトコルの一部として定義する必要があることを提案します。単一のAAAメッセージには、異なる管理ドメインからAAAサーバーによって生成され、AAAサーバーに運命づけられている複数の情報ユニットが含まれる可能性があるため、[3]のセクション2.2.7で指定されたエンドツーエンドのセキュリティ要件を満たすには、この粒度を伴うセキュリティが必要です。異なるドメインで。
In addition, it may be necessary to encrypt or sign an entire AAA message on a hop-by-hop basis. This could be handled by a standard, lower layer protocol such as IPSEC. If so, then certain auditing requirements will have to be met so that it can be established later that the messages relative to some specific session ID were, in fact, protected in a particular way. Alternatively, hop-by-hop security mechanisms may be built into the base AAA protocol itself.
さらに、ホップバイホップベースでAAAメッセージ全体を暗号化または署名する必要がある場合があります。これは、IPSECなどの標準の下層層プロトコルによって処理できます。もしそうなら、特定のセッションIDに対するメッセージが実際に特定の方法で保護されていることを後で確立できるように、特定の監査要件を満たす必要があります。あるいは、ホップバイホップセキュリティメカニズムをベースAAAプロトコル自体に組み込むことができます。
Glossary
用語集
Application Specific Information (ASI) -- information in an AAA protocol message that is specific to a particular application.
アプリケーション固有の情報（ASI） - 特定のアプリケーションに固有のAAAプロトコルメッセージ内の情報。
Application Specific Module (ASM) -- a software module that implements a program interface to a generic AAA server which handles application specific functionality for an AAA protocol message.
アプリケーション固有モジュール（ASM） - AAAプロトコルメッセージのアプリケーション固有の機能を処理する汎用AAAサーバーにプログラムインターフェイスを実装するソフトウェアモジュール。
Service Provider -- an organization which provides a service.
サービスプロバイダー - サービスを提供する組織。
User -- the entity seeking authorization to use a resource or a service.
ユーザー - リソースまたはサービスを使用する許可を求めているエンティティ。
User Home Organization (UHO) -- An organization with whom the User has a contractual relationship which can authenticate the User and may be able to authorize access to resources or services.
ユーザーホーム組織（UHO） - ユーザーがユーザーを認証できる契約上の関係を持ち、リソースまたはサービスへのアクセスを許可できる組織。
References
参考文献
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[2] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, D., Holdrege, M. and D. Spence, "AAA Authorization Framework", RFC 2904, August 2000.
[2] Vollbrecht、J.、Calhoun、P.、Farrell、S.、Gommans、L.、Gross、G.、De Bruijn、B.、De Laat、D.、Holdrege、M。and D. Spence、 "AAA Authorization Framework"、RFC 2904、2000年8月。
[3] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Application Examples", RFC 2905, August 2000.
[3] Vollbrecht、J.、Calhoun、P.、Farrell、S.、Gommans、L.、Gross、G.、De Bruijn、B.、De Laat、C.、Holdrege、M。and D. Spence、 "AAA認証申請書例」、RFC 2905、2000年8月。
[4] Farrell, S., Vollbrecht, J., Calhoun, P., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Requirements", RFC 2906, August 2000.
[4] Farrell、S.、Vollebrecht、J.、Calhoun、P.、Gommans、L.、Gross、G.、De Bruijn、B.、De Laat、C.、Holdrege、M。and D. Spence、 "AAA認定要件"、RFC 2906、2000年8月。
[5] Blaze, M., Feigenbaum, J., Ioannidis, J. and A. Keromytis, "The KeyNote Trust-Management System Version 2", RFC 2704, September 1999.
[5] Blaze、M.、Feigenbaum、J.、Ioannidis、J。、およびA. Keromytis、「The Keynote Trust-Management Systemバージョン2」、RFC 2704、1999年9月。
Authors' Addresses
著者のアドレス
Cees T.A.M. de Laat Physics and Astronomy dept. Utrecht University Pincetonplein 5, 3584CC Utrecht Netherlands
CEES T.A.M.デラート物理学と天文学部。ユトレヒト大学ピンセトンプリン5、3584ccユトレヒトオランダ
Phone: +31 30 2534585
Phone: +31 30 2537555
EMail: delaat@phys.uu.nl
George M. Gross Lucent Technologies 184 Liberty Corner Road, m.s. LC2N-D13 Warren, NJ 07059 USA
George M. Gross Lucent Technologies 184 Liberty Corner Road、M.S。LC2N-D13 WARREN、NJ 07059 USA
Phone: +1 908 580 4589 Fax: +1 908-580-4991 EMail: gmgross@lucent.com Leon Gommans Enterasys Networks EMEA Kerkplein 24 2841 XM Moordrecht The Netherlands
電話：1 908 580 4589 FAX：1 908-580-4991メール：gmgross@lucent.com leon gommans enterasysネットワークEmea kerkplein 24 2841 xm Moordrecht The Notherlands
Phone: +31 182 379279
email: gommans@cabletron.com
or at University of Utrecht:
l.h.m.gommans@phys.uu.nl
John R. Vollbrecht Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA
John R. Vollbrecht Interlink Networks、Inc。775 Technology Drive、Suite 200 Ann Arbor、MI 48108 USA
Phone: +1 734 821 1205
Fax: +1 734 821 1235
EMail: jrv@interlinknetworks.com
David W. Spence Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA
David W. Spence Interlink Networks、Inc。775 Technology Drive、Suite 200 Ann Arbor、MI 48108 USA
Phone: +1 734 821 1203
Fax: +1 734 821 1235
EMail: dspence@interlinknetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。