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
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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サーバのネットワークを通じて実現されることを可能にする一般的なフレームワークを作成することです。
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ワーキンググループのチャーターはモバイルIPとNASの要件に焦点を当てるように変更された場合は、AAAarch研究グループは、承認サブグループによって開始された建築作業を継続して展開するIRTF以内にチャーターされました。このメモは、サブグループによって作成された4の一つです。このメモはAAAarch研究グループ内でさらなる作業の出発点です。それはまだ進行中の作業で、作業が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]、多数の応用例で示さ[3]次に、認可要件の提案されたリストの動機た[4]。このメモは、標準プロトコルを介して通信する一般的な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部は、アプリケーション固有の処理に適したASMへのプログラムインターフェースを介して汎用のAAAサーバによって渡されることになります。それにもかかわらず、それは一般的なルールベースのエンジンによって処理を可能にするように、可能な限り標準的な方法でエンコードされる情報ユニットの設計の目標のまま。
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サーバとの相互作用は、セクション3で、次にセクション2で検討されている、我々はさらに抽象化レイヤリングプロトコルを使用して論理グループに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]ので、個別にアプリケーション固有の情報単位に、このような公開鍵暗号化やデジタル署名などのセキュリティ技術を適用することにより、一般的なサーバーとアプリケーション固有のモジュールで満たすことができる方法を示していますその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サーバは、論理規則を知っているし、要求内のいくつかの一般的な情報を理解するであろう、この時点では、ルールベースのエンジンを持っているでしょうが、それは、この情報はブール値を与えるために評価またはことができる場合を除き、アプリケーション固有の情報については何も知らないだろう数値。アプリケーションが作成されたときに考慮されなかったデータ要素を参照するルールを作成することが可能です。例えば、1は、ダイヤルイン・プロバイダーを使用して自宅からリモート仮想制御室の実験を行うことを要求することができます。利用可能（帯域幅ブローカー）と実験者がそれを支払うためにお金（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>
ユーザー< - >ダイヤルイン< - > BBとバックボーン< - > <遠隔実験>
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型プロトコルのこれ以上言いません。同じリポジトリにアクセスするために使用されるタイプ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）ユニット内にカプセル化されるべき値のペア属性可能にしますサービスプロバイダのAAAサーバとわずかに信頼されたプロキシAAAサーバを介して通信するホームAAAサーバの間で。サービスプロバイダのNASは、サービスプロバイダーの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は、いくつかのプロトコルを介してサービスと通信します。これら二つの可能性は、両方の場合において、図4に示されているが、我々は、もちろん、サービスの特定の通信タイプ5としてASMとサービス間の通信を標識しました。
| |
+--------------|----+ |
| 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（二つのビュー）
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:
上記の様々な機能を整理する一つの方法は、層状の階層に割り当てることであろう。実際には、我々は層のパラダイムは、AAAの機能を理解するのに有用な1であることがわかってきました。このセクションでは、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サービスの我々の見解では、協力してそのサービス層の機能を実現する責任があり、各サービス層での分散プロセスのセットがあります。これらのプロセスは、それらのサービスレイヤに割り当てられた機能と責任を実行するために特化したプロトコルを用いて互いに通信します。サービス層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.
- 一つの層の要求は、他の層で動作するプロトコルに影響を与えることなく満たすことができます。たとえば、ローカルのセキュリティ要件は、より強いまたは弱い「信頼性の高い安全な輸送」層のセキュリティ・アルゴリズムまたはプロトコルの置換を指示することができます。これらは、信頼できる/安全なトランスポート層以上の層による置換の変化がないか、意識して導入することができます。
- 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プロトコルメッセージ（例えばRADIUSメッセージ）は、既存の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）サービス層（3.4節を参照）でプロトコルを実装するために義務的なものを指定するAAAプロトコルの標準化作業の第一の目標でなければなりません。
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
- 彼らは第1の動作を開始するとき、互いを発見し、
- 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-1アクセスポイントを介して受信したピアサービス層N終点からプロトコルデータユニットの到着
- 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アーキテクチャは、将来的には他の抽象基本オブジェクトクラス（例えば認可予約、認証サーバなど）を含むように拡張することができます。与えられた問題領域の派生認証サーバークラスのパブリックメソッドを実装する方法完全アプリケーション次第です。一つの技術は、標準化された認証サーバーオブジェクトのパラダイムに適合するように、既存の組み込みアプリケーション固有のサービスを中心にソフトウェア「ラッパー」を配置することであるかもしれません。主要な認証サーバークラスのメソッドは以下のとおりです。
- 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.
- 認証サーバーのサービス属性とそのアプリケーション固有のサービス層のエンドポイントアドレスを記述する広告を公開します。認証サーバが登録されると、ピアプロセスは、その存在を発見したり、それに宛てたメッセージを送ることができます。
- 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.
- 認証サーバーのサービス広告を撤回。
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サーバベースの外部ルールに割り当てることができます。これは、中央リポジトリにAAAポリシーを展開セキュリティ管理を容易にするであろう（アイデアが[5]で定義された信頼管理ポリシーサーバと同様です）。 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.
より良いプレゼンテーション層の役割を理解するための一つの方法は、既存の例を評価することです。ジェネリックORB間プロトコル（GIOP）とその共通データ表現（CDR）は、オブジェクト管理グループ（OMG）業界のコンソーシアムによって開発されたプレゼンテーションサービス層プロトコルです。 GIOPは、共通オブジェクト・リクエスト・ブローカ・アーキテクチャ（CORBA）内の1つの構成要素です。異種システム上で実行するピア・オブジェクト・リクエスト・ブローカー（ORB）は、リモートCORBAオブジェクト・インタフェース・メソッドを呼び出すためにGIOPを使用します。 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）パラダイムを使用します。このようなアプローチは、汎用性の高いですが、それはまた、多くの広告アドホックおよびベンダー固有の方言に分裂なるための傾向があります。全く課される構造またはのAVPを合わせ、AAAプロトコルの実装または問題のドメイン間で一貫した方法で所与の会話のために解釈された制約条件を交渉する方法はありません。通信ピアがの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:
AAAトランザクション/セッション管理（AAA-TSM）サービス層は、典型的には、異なる管理ドメインに存在するAAAサーバの分散型セットです。総称して、彼らは、次の3つのサービスを担当しています。
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 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-TSMメッセージは、これらのAAA機能を実現します。中央の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-TSMメッセージを交換するAAAサーバの必要性を回避します。他の利点は、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）と呼ばれる抽象オブジェクトを介してです。これら二つの層の間に特定のサービスインスタンスが許可セッションと呼ばれる抽象オブジェクトで実現されます。プレゼンテーションサービス層は、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タプルです。
- 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 Serverシステムを再起動する間で回復可能であることが必要です。シリアル番号の生成アルゴリズムは、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
このメモは、自然の中で一般的な、多くの異なるAAAアプリケーションに共通しているAAA機能の基本セットを識別します。我々は、セキュリティ・メカニズムの標準セットは、AAAメッセージ内の個々の情報単位に適用することができる公開鍵暗号化およびデジタル署名のようなものが含まれるベースAAAプロトコルの一部として定義されるべきであることを提案します。この粒度を有するセキュリティはセクション2.2.7で指定されたエンドツーエンドのセキュリティ要件を満たすために必要とされる[3]単一AAAメッセージは、可能性があるため
contain multiple information units each generated by AAA servers from different administrative domains and destined to AAA servers in different domains.
それぞれ異なる管理ドメインのAAAサーバによって生成され、異なるドメイン内のAAAサーバ宛ての複数の情報ユニットを含みます。
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]ブラドナーの、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.、カルフーン、P.、ファレル、S.、Gommans、Bruijnグラフ、B.、デLAAT、D.、ホールドレッジ、M.とD.スペンスデL.グロス、G.、 " AAA認証フレームワーク」、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.、カルフーン、P.、ファレル、S.、Gommans、Bruijnグラフ、B.、デLAAT、C.、ホールドレッジ、M.とD.スペンスデL.グロス、G.、 " 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]ファレル、S.、Vollbrecht、J.、カルフーン、P.、Gommans、Bruijnグラフ、B.、デLAAT、C.、ホールドレッジ、M.とD.スペンスデL.グロス、G.、 " 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]ブレイズ、M.、ファイゲンバウム、J.、Ioannidis、J.及びA. Keromytis、 "基調信託管理システムバージョン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.物理学や天文学DEPTをしてみましょう。ユトレヒト大学Pincetonplein 5、3584CCユトレヒトオランダ
Phone: +31 30 2534585 Phone: +31 30 2537555 EMail: delaat@phys.uu.nl
電話：+31 30 2534585電話：+31 30 2537555 Eメール：delaat@phys.uu.nl
George M. Gross Lucent Technologies 184 Liberty Corner Road, m.s. LC2N-D13 Warren, NJ 07059 USA
ジョージM.総ルーセント・テクノロジーズ184リバティ・コーナーの道、M.S。 LC2N-D13ウォーレン、NJ 07059 USA
Phone: +1 908 580 4589 Fax: +1 908-580-4991 EMail: gmgross@lucent.com
電話：+1 908 580 4589ファックス：+1 908-580-4991電子メール：gmgross@lucent.com
Leon Gommans Enterasys Networks EMEA Kerkplein 24 2841 XM Moordrecht The Netherlands
レオンGommansのEnterasys NetworksのEMEA Kerkplein 24 2841 XMオランダMoordrecht
Phone: +31 182 379279 email: gommans@cabletron.com or at University of Utrecht: l.h.m.gommans@phys.uu.nl
電話：+31 182 379279 Eメール：gommans@cabletron.comやユトレヒト大学：l.h.m.gommans@phys.uu.nl
John R. Vollbrecht Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA
ジョンR. Vollbrechtインターリンクネットワークス株式会社775テクノロジードライブ、スイート200アナーバー、MI 48108 USA
Phone: +1 734 821 1205 Fax: +1 734 821 1235 EMail: jrv@interlinknetworks.com
電話：+1 734 821 1205ファックス：+1 734 821 1235 Eメール：jrv@interlinknetworks.com
David W. Spence Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA
デビッドW.スペンスインターリンクネットワークス株式会社775テクノロジードライブ、スイート200アナーバー、MI 48108 USA
Phone: +1 734 821 1203 Fax: +1 734 821 1235 EMail: dspence@interlinknetworks.com
電話：+1 734 821 1203ファックス：+1 734 821 1235 Eメール：dspence@interlinknetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。