RFC2903 日本語訳
2903 Generic AAA Architecture. C. de Laat, G. Gross, L. Gommans, J.Vollbrecht, D. Spence. August 2000. (Format: TXT=60627 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
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
Commentsのために作業部会C.de Laat Requestをネットワークでつないでください: 2903年のユトレヒト大学カテゴリ: 実験G.総計のルーセントテクノロジーズL.Gommans EnterasysネットワークEMEA J.Vollbrecht D.スペンスはInc.2000年8月にネットワークを連結します。
Generic AAA Architecture
ジェネリックAAAアーキテクチャ
Status of this Memo
この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.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
このメモはAuthenticationを提案します、Authorization、アプリケーション・インターフェースに伴うジェネリックAAAサーバをアプリケーションの特定のAAA機能を実行できたApplication Specific Modulesの1セットまで取り入れるAccounting(AAA)アーキテクチャ。 そして、マルチドメイン環境で必要であるAAA機能の分離は、層にされたプロトコル抽象化を使用することで提案されます。 長期目標は複雑な承認がインタコネクトされたAAAサーバのネットワークを通して実現するジェネリックフレームワークを作成することです。
de Laat, et al. Experimental [Page 1] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [1ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
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
1. 序論… 2 2. ジェネリックAAAアーキテクチャ… 4 2.1. ジェネリックAAAサーバの建築構成… 4 2.1.1. 承認規則評価… 4 2.1.2. アプリケーションの特定のモジュール(ASM)… 5 2.1.3. 承認イベントログ… 6 2.1.4. 方針倉庫… 6 2.1.5. 推進を要求してください… 6 2.2. ジェネリックAAAサーバモデル… 6 2.2.1. ジェネリックAAAサーバ相互作用… 7 2.2.2. レガシープロトコルとの互換性… 7 2.2.3. ASMとサービスとの相互作用… 9 2.2.4. マルチドメイン構造… 10 2.3. 観測をモデル化してください… 10 2.4. 未来の提案は働いています… 11 3. AAAプロトコルモデルを層にします… 12 3.1. 階層化アーキテクチャのElements… 14 3.1.1. 層の抽象的なインタフェース基関数を修理してください… 14 3.1.2. 層の同輩エンドポイント名前スペースを修理してください… 14 3.1.3. 同輩登録、発見、および位置の解決… 14 3.1.4. 同輩エンドポイントの間の関係を信じてください… 14 3.1.5. 層の有限状態機械を調整してください… 15 3.1.6. プロトコルデータ単位はタイプされます… 15 3.2. AAAのアプリケーションの特定のサービス層… 15 3.3. プレゼンテーション・サービス層… 16 3.4. AAAトランザクション/セッション経営者側は層を調整します… 17 3.5. AAA-TSMは層のプログラムインタフェース基関数を修理します… 20 3.6. AAA-TSMはエンドポイント名前スペースを層にします… 21 3.7. スタックの例について議定書の中で述べてください… 22 4. セキュリティ問題… 22用語集… 23の参照箇所… 24人の作者のアドレス… 24 完全な著作権宣言文… 26
1. Introduction
1. 序論
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
このメモのための仕事が元々IETFのAAA作業部会のAuthorizationサブグループであったグループによって行われました。 MobileIPとNAS要件に焦点を合わせるためにAAAワーキンググループの特許を変えたとき、Authorizationサブグループによって始められた建築仕事を続けて、広げるためにIRTFの中でAAAarch Research Groupをチャーターしました。 このメモはサブグループによって作成された4の1つです。 このメモはAAAarch Research Groupの中のさらなる仕事のための出発点です。 それでも、それは処理中の作業です。
de Laat, et al. Experimental [Page 2] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [2ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
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.
そして、利用可能である仕事がなる発行されたそうは、アーキテクチャか要件の決定的な記述で働いているのではなく、この領域で働いている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作業部会の承認サブグループは順番に承認要件[4]の提案されたリストを動機づける多数のアプリケーションの例[3]で例証された「AAA承認フレームワーク」[2]を提案しました。 フレームワークに関する体格が協力するネットワークから成るAAAインフラストラクチャを提案するのによる[2]に標準プロトコルで交信するジェネリックAAAサーバを提示したこのメモ。 プロトコルは、かなり一般的であるべきであり、AAAの機能性を必要とするさまざまなアプリケーションの必要性をサポートするべきです。 この目標がわかるために、プロトコルは、実体と同様に複数のサービスプロバイダーがUserホームOrganizationsやブローカーなどの他の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サービスを必要とするアプリケーションはそれぞれそれら自身のユニークな必要性を持つでしょう。 サービスが認可されていた後に、それを構成されて、初期化しなければなりません。 これは、アプリケーションの特定の知識を必要として、アプリケーションの特定のサービスコンポーネントで交信するためにアプリケーションの特定のプロトコルを必要とするかもしれません。 これらのアプリケーション具体的な機能を扱うために、私たちは各アプリケーションで必要であるユニークな機能性を行うことができる1Application Specific Modules(ASMs)のジェネリックAAAサーバとセットとのアプリケーション・インターフェースを提案します。
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プロトコルは不透明なユニットのApplication Specific情報(ASI)のカプセル化を許容するべきです。 これらのユニットは、標準のヘッダーと共にそれらがジェネリックインフラストラクチャによって進められるのを許容し始めるでしょう。 最終的な送付先に提供されると、ASIユニットはアプリケーションの特定の処理のためにプログラムインタフェースの向こう側にジェネリックAAAサーバによって適切なASMに通過されるでしょう。 それにもかかわらず、デザインの目標のままで、情報ユニットが標準の方法でできるだけコード化されるのは、ジェネリックの規則のベースのエンジンで処理を可能にするために残っています。
de Laat, et al. Experimental [Page 3] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [3ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
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.
Application Specific Modulesと互いとの複雑な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で、私たちはジェネリックサーバとApplication Specific Modulesで個別に公開鍵暗号化かデジタル署名などのセキュリティのテクニックをApplication Specific情報ユニットに適用することによってどう[4]で特定されたセキュリティ必要条件は満たすことができるかを示しています、AAAサーバネットワークにおける認証、承認、または会計チェーンでそのほかの利害関係者によって解読されるか、または変更されるのと異なった利害関係者が選択された情報ユニットを保護できるように。
2. Generic AAA Architecture
2. ジェネリック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コンポーネントは、承認機能を実行しながら、他の管理ドメインで配布されるでしょう。
2.1. Architectural Components of a Generic AAA Server
2.1. ジェネリックAAAサーバの建築構成
2.1.1. Authorization Rule Evaluation
2.1.1. 承認規則評価
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
承認プロセスの第一歩はよくフォーマットされた要求をAAAサーバに提出するためにユーザの代理を作動させるユーザか実体のためのものです。ジェネリックAAAサーバには、要求を点検して、承認結論に達する規則(論理、そして/または、代数的な定石)があります。 起こる第1の問題はApplication Specific情報(ASI)が承認のために基本的な論理と切り離されなければならないということです。 理想的に、AAAサーバは、規則がここの論理規則を知っているエンジンを基礎づけて、要求における何らかのジェネリック情報を理解しているのをさせるでしょうが、論理演算子か数値を与えるためにこの情報を評価できるところ以外に、それはアプリケーション特殊情報に関して何も知らないでしょう。 それが示す規則を作成するのは可能であるべきです。
de Laat, et al. Experimental [Page 4] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [4ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
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.
アプリケーションであるときに、考えられなかったデータ要素は作成されました。 例えば、人は、遠く離れた仮想の制御室をするために、ホームからdialinプロバイダーを使用することで実験するよう要求できました。 dialinアクセス・サーバーがそれを許容して、利用可能な帯域幅(帯域幅ブローカー)があって、実験者が(電子Commerce)であるのに支払うそれのお金を持っている場合にだけ、要求はうまくいっているでしょう。 ことによると帯域幅ブローカープロトコルを指定した人々は、ただ一つのAAA要求におけるネットワーク・サービス承認にサービスの質を結合することを考えませんでしたが、このジェネリックモデルはそれを許容するでしょう。
+------+ +-------+ +-------+ +-------+ +-------+ | | auth | | auth | | auth | | auth | | | |<---->| AAA |<---->| AAA |<---->| AAA |<---->| AAA | | | | | | | | | | | | | +-------+ +-------+ +-------+ +-------+ | User | | | | | | | | +-------+ +-------+ +-------+ | | | | BB | | BB | |Budget | | | | +-------+ +-------+ +-------+ | | | | | | | +-------+ | | | | |dial in| +-------+ +-------+ | |<====>|service|<====>|network|<====>|network|<===> Experiment +------+ +-------+ +-------+ +-------+
+------+ +-------+ +-------+ +-------+ +-------+ | | auth| | auth| | auth| | auth| | | | <、-、-、--、>| AAA| <、-、-、--、>| AAA| <、-、-、--、>| AAA| <、-、-、--、>| AAA| | | | | | | | | | | | | +-------+ +-------+ +-------+ +-------+ | ユーザ| | | | | | | | +-------+ +-------+ +-------+ | | | | 掲示板| | 掲示板| |予算| | | | +-------+ +-------+ +-------+ | | | | | | | +-------+ | | | | |直通電話にかけてください。| +-------+ +-------+ | |<==>|サービス|<==>|ネットワーク|<==>|ネットワーク|<==>実験+------+ +-------+ +-------+ +-------+
user <-> dialin <-> backbone with BB <-> <remote experiment>
掲示板の<->の<のリモート実験>があるユーザ<->dialin<->バックボーン
Fig. 1 -- Example of a Multi Domain Multi Type of Server Request
図1--サーバ要求のマルチドメインマルチタイプに関する例
2.1.2. Application Specific Module (ASM)
2.1.2. アプリケーションの特定のモジュール(ASM)
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)は、アプリケーションの特定のユーザ承認機能を実行するためにまた、ASMsを必要とするかもしれません。 例えば、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
承認決定に比例した管理、ジェネリックAAAサーバの能力、およびそれとASMsとのインタフェースの役割が同じように残っていることなら何でも。 このインタフェースはApplication Program Interface(API)であるかもしれないかプロトコルがインタフェースを基礎づけたということでさえあるかもしれません。 しかしながら、これでは、アプリケーションをモデル化してください。
de Laat, et al. Experimental [Page 5] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [5ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
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サーバからの別々の建築コンポーネントのように見なされます。それは、そういうものとして、アドレス可能でなければならなく、したがって、グローバルな命名スペースの一部であるに違いありません。
2.1.3. Authorization Event Log
2.1.3. 承認イベントログ
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サーバで起こる時間で押し込まれたイベントを保存する何らかのフォームに関するデータベースがなければなりません。与えられた承認を説明するのにこのデータベースを使用できますが、また、規則でそれは使用できます。 人はある他のイベントが過去に登録された場合にだけ承認が与えられる規則を想像できます。 証明書の援助で、このデータベースは非拒否をサポートするかもしれません。
2.1.4. Policy Repository
2.1.4. 方針倉庫
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サーバからアドレス可能でなければならないので、また、サービスとリソースのための命名スペースも重要です。
2.1.5. Request Forwarding
2.1.5. 推進を要求してください。
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サーバが交信するプロトコルはピアツーピアプロトコルであるべきです。
2.2. Generic AAA Server Model
2.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要求を扱うことができるでしょう。 それは、さらにそれぞれの要求の成分を処理するために要求のコンテンツを点検して、どんな承認が要求されているかを決定して、倉庫から政策ルールを検索して、様々な地方の機能を実行して、次に、以下のオプションの1つを選ぶでしょう:
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.
以下のセクションでは、私たちはジェネリックモデルを提示します。
de Laat, et al. Experimental [Page 6] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [6ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
2.2.1. Generic AAA Server Interactions
2.2.1. ジェネリックAAAサーバ相互作用
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 Serverが上で説明したジェネリックを例証します。 このモデルで、ユーザか別の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 |
+------------------+
+------------------+ | | <を要求してください。-----1----->|ジェネリックAAAサーバ| <、-、--1--->AAAサーバ|ベースのエンジンを統治してください。| | |\ +------------------+ 3 +------------+ ^ \| そして方針。| | | イベント| 2 | 倉庫| | +------------+ +に対して------------------+ | アプリケーション| | 特定| | モジュール| +------------------+
The numbers in the links denote types of communication.
リンクの数はコミュニケーションのタイプを指示します。
Fig. 2 -- Generic AAA Server Interactions
図2--ジェネリックAAAサーバ相互作用
2.2.2. Compatibility with Legacy Protocols
2.2.2. レガシープロトコルとの互換性
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
レガシーAAAプロトコルを実装する設備の広範囲の展開と既存のインフラストラクチャへの投資を保護している間に新しいAAAプロトコルの機能性がわかる願望のために、新しいプロトコルに関するメッセージの中でレガシープロトコルデータがユニットであるとカプセル化することができるAAAゲートウェイ機能を実装するのは役に立つかもしれません。 終わりから終わりへの保護のためにわずかに信じられたプロキシAAAサーバで交信しながら、サービスプロバイダーのAAAサーバとホームAAAサーバの間でASIユニットにデジタルに署名して、暗号化できます。例えば、このテクニックの使用は、Radius属性値組がサービスプロバイダーのNASがサービスへのRadiusを通って交信するような方法で新しいプロトコルのApplication Specific情報(ASI)ユニットでカプセル化されるのを許容するでしょう。
de Laat, et al. Experimental [Page 7] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [7ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
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プロトコルで交信するでしょう。 この場合、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はApplication Specific Modules(ASMs)かService Equipmentにアプリケーションの特定のコミュニケーションに賛成します。
+-------+
| AAA |<---1---> to AAA server as in fig. 2
request <---4--->|GateWay|
| |<---2---> optionally to ASM/service
+-------+
+-------+ | AAA| <、-、--1--->、AAAサーバに、2は図のように<を要求します。---4--->|ゲートウェイ| | | <、-、--2--->は任意にASM/に+を修理します。-------+
The numbers in the links denote types of communication.
リンクの数はコミュニケーションのタイプを指示します。
Fig. 3 -- AAA Gateway for Legacy AAA Protocols
図3--レガシーAAAプロトコルのためのAAAゲートウェイ
de Laat, et al. Experimental [Page 8] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [8ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
2.2.3. Interaction between the ASM and the Service
2.2.3. ASMとサービスとの相互作用
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.
サービスプロバイダーでは、Application Specific Module(ASM)とサービス自体を提供するソフトウェアはしっかり単一の「サービスアプリケーション」に向かうかもしれません。 この場合、それらの間のインタフェースはただソフトウェア・インタフェースです。 しかし、ASM、例えば、ルータへの外部の設備は帯域幅ブローカーアプリケーションにサービス自体を提供するかもしれません。 この場合、ASMはサービスで何らかのプロトコルで交信します。 これらの2つの可能性は例証されて、4が中で計算するということです。 どちらの場合も、私たちがコミュニケーションタイプとしてのASMとサービスとのコミュニケーションを5とラベルした、どれ、もちろん、サービス詳細はそうであるか。
| |
+--------------|----+ |
| Service 2 | 2
| Application | | |
| +-------------+ | +-------------+
| | Application | | | Application |
| | Specific | | | Specific |
| | Module | | | Module |
| +-------------+ | +-------------+
| | | |
| 5 | 5
| | | |
| +-------------+ | +-------------+
| | Service | | | Service |
| | | | | Equipment |
| +-------------+ | +-------------+
+-------------------+
| | +--------------|----+ | | サービス2| 2 | アプリケーション| | | | +-------------+ | +-------------+ | | アプリケーション| | | アプリケーション| | | 特定| | | 特定| | | モジュール| | | モジュール| | +-------------+ | +-------------+ | | | | | 5 | 5 | | | | | +-------------+ | +-------------+ | | サービス| | | サービス| | | | | | 設備| | +-------------+ | +-------------+ +-------------------+
Fig. 4 -- ASM to Service Interaction (two views)
図4--サービス相互作用へのASM(2つの視点)
de Laat, et al. Experimental [Page 9] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [9ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
2.2.4. Multi-domain Architecture
2.2.4. マルチドメイン構造
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 | +----+
| |
+-----+
+-----+ o--------| AAA|---->… / | | / +-----+\ / | \+----+ / +-----+ | RP| / | ASM| +----+ +--------+ +-----+ / | | | クライアント|------| 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--サービスアーキテクチャのマルチドメインマルチタイプ
2.3. Model Observations
2.3. モデル観測
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) アプリケーションの特定のサービスに関してGeneric AAAサーバには知識が全くないので、それが転送するアプリケーション特殊情報はそれに不明瞭です。
de Laat, et al. Experimental [Page 10] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [10ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
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プロトコルメッセージで結合されるために複数の異なった管理ドメインの複数の異なったアプリケーションに属す複数の異なったサービスのための情報ユニットを許容するべきです。
2.4. Suggestions for Future Work
2.4. 今後の活動のための提案
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
これらの領域に加えて、ジェネリックマルチドメインAAAインフラストラクチャの開発と今後の展開が管理可能性に主に依存しているのでマルチドメインAAA環境における規則の管理を探る必要があります。 何らかの形式の自動化された規則作成と家事がなければ、多くの規則がいくつかのAAAサーバの上ですぐに分配したマルチドメインAAA環境住宅は「非-処理しやす」になります。 彼らのサービスが何らかのフォームの商業契約に基づく規則で治められるのを許容する組織が最少で実装するべき契約を必要とします。
de Laat, et al. Experimental [Page 11] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [11ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
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サーバの間で政策ルール設立を必要とします。
3. Layered AAA Protocol Model
3. 層にされた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.
前項で、私たちはインタフェースで1Application Specific Modules(ASMs)にジェネリックAAAサーバの考えを提案しました。 ジェネリックサーバは異なった管理ドメインでサーバの間のAAAメッセージの推進を含む多くの一般的な機能を扱うでしょう。 私たちは、メッセージ転送、ホップごとのセキュリティ、およびメッセージ推進が同じくらい明確にジェネリックサーバの機能であることを思い描きます。アプリケーションの特定のモジュールはサービス設備とのコミュニケーションや専用データベースへのアクセスなどのすべてのアプリケーションの特定のタスクを扱うでしょう。 これらの2セットの機能の間に、おそらく、ジェネリックサーバかASMのどちらかかことによると両方の共同で行われることができるだろう別の関数群はあります。 これらの機能は承認要求自体からの属性を含んでいて、様々な場所にあるかもしれないデータに対して承認規則の評価を含んでいます。 私たちがさらにジェネリックサーバまでこれらの機能を押し下げることができれば、ジェネリックサーバがそうであることができ、ASMsが簡単である場合があれば、より強力です。
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サーバと前項で提案されたASMsとのインタフェースは簡単な層にされたモデルが許容するだろうより複雑であるかもしれません。 このセクションで提案された機能性の分割さえレイヤリングの厳しい理解を越えます。 したがって、仕事の始まりとしてAAAプロトコルの作成のために熟している規範モデルとしてというよりむしろ汎用のAAAインフラストラクチャに必要である一般的な機能性を理解して、組織化するのをこの紙を特にたぶん理解できます。
de Laat, et al. Experimental [Page 12] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [12ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
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サービスの意見には、それぞれのサービス層の1セットの協力している、そのサービス層の機能を実装するのに原因となる分配されたプロセスがあります。 これらのプロセスは機能を行うために専門にされたプロトコルを使用する互いとそれらのサービス層に選任される責任で交信します。 サービス層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つの層の必要条件は、他の層で作動しながら、プロトコルで影響なしで満たされるかもしれません。 例えば、地方のセキュリティ要件は、より強いか、より弱い「信頼できる安全な輸送」層のセキュリティアルゴリズムかプロトコルの代替を決めるかもしれません。 Reliable/安全なTransport層の上の層のそばで代替の変化も認識なしでこれらを導入できます。
- 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インフラストラクチャへのService ProviderかUserホームOrganizationの投資を保持して。
- 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 Transaction/セッションManagement(AAA-TSM)サービス層でプロトコルを実装するために義務的な1つを指定するのは、AAAプロトコル標準化取り組みのプライマリ目標であるべきです(セクション3.4を見てください)。
de Laat, et al. Experimental [Page 13] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [13ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
3.1. Elements of a Layered Architecture
3.1. 階層化アーキテクチャのElements
At each layer of a layered architecture, a number of elements need to be defined. These elements are discussed in the following sections.
階層化アーキテクチャの各層では、多くの要素が、定義される必要があります。 以下のセクションでこれらの要素について議論します。
3.1.1. Service Layer Abstract Interface Primitives
3.1.1. 層の抽象的なインタフェース基関数を修理してください。
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がアクセスできるプログラムインタフェースにサービスを提示すると思われます。 これらのサービス層の間の境界の向こう側に交換された抽象的なプログラム・サービス基関数と関連パラメタのタイプを指定しなければなりません。
3.1.2. Service Layer Peer End Point Name Space
3.1.2. サービス層の同輩エンドポイント名前スペース
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.
それぞれのサービス層は複数のコンピューティング・システムの向こう側に分配された1セットの協調処理として扱われます。サービス層はこれらの同輩プロセスを特定するエンドポイント名前スペースを管理しなければなりません。 サービス層がそのようなそれぞれの同輩プロセスにユニークなエンドポイント名を割り当てるコンベンションを指定しなければなりません。
3.1.3. Peer Registration, Discovery, and Location Resolution
3.1.3. 同輩登録、発見、および位置の解決
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セットのサービスが検索評価基準に合っている1つ以上の同輩エンドポイント名に特定の検索属性を層にすると決議するために存在するかを指定するのも必要です。
3.1.4. Trust Relationships Between Peer End Points
3.1.4. 同輩エンドポイントの間の信頼関係
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.
エンドポイントがいったん別の同輩との初期接触を設置すると、それは、どんな認証方針を適合させたらよいかを決めなければなりません。 それは、低級サービス層のそばでそのに代わって行われたどんな認証も信じるか、プレの食糧を供給するプロセスを通してそれとなく同輩を信じるか、または同輩と共に認証過程に直面できます。 サービス層のエンドポイント信頼関係を確立するためのサポートしているメカニズムを指定しなければなりません。
de Laat, et al. Experimental [Page 14] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [14ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
3.1.5. Service Layer Finite State Machine
3.1.5. 層の有限状態機械を調整してください。
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:
サービス層の内部の州が外部的に目に見えるという範囲まで、Finite州Machine(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
- タイマ満期
3.1.6. Protocol Data Unit Types
3.1.6. プロトコルデータユニット型
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.
それぞれのサービス層は、層の同輩プロセスの間でそのサービス層の分散状態を制御する、そして/または、モニターする情報を伝えるプロトコルデータ単位(PDUs)のレキシコンを定義して、その層のサービス過程がそれらの機能を実行するのを許容します。 それぞれの層のPDUsに埋め込まれているのは、サービスによるより高い層のPDUsです。 それぞれのサービス層のPDUsを指定しなければなりません。
3.2. AAA Application Specific Service Layer
3.2. AAAのアプリケーションの特定のサービス層
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アプリケーションがそれらのアプリケーション具体的計画論理に標準化された「承認サーバ」抽象的なベースオブジェクトのクラスに由来しているでしょう。 また、彼らは「認可されたセッション」オブジェクトのクラスをサポートするでしょう。 Authorization Sessionオブジェクトインスタンスはサービスかリソースの長命の配分を持っている承認された承認要求を表します。 将来(例えば、Authorization予約、Authentication Serverなど)他の抽象的なベースオブジェクトのクラスを含むようにジェネリックAAAアーキテクチャを広げることができました。 派生しているAuthorization Serverのクラスのsが公共のメソッドであるとどう与えられた問題ドメインに実装するかが完全にアプリケーションまで達しています。 1つのテクニックは標準化されたAuthorization Serverオブジェクトパラダイムにそれを適合させるために既存の埋め込まれたアプリケーション特定のサービスの周りの「ラッパー」というソフトウェアを置くことであるかもしれません。 主要なAuthorization Serverクラスメソッドは以下の通りです。
de Laat, et al. Experimental [Page 15] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [15ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
- 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.
- 別の利害関係者は、Specific Authorization Decision Function(AS-ADF)メソッドがUserのアプリケーションの特定の承認要求を取って、決定を返すアプリケーションに承認するか、否定するか、または紹介で条件付きに承認します。 後者の場合では、アプリケーションは要求されたサービスかリソースの予約を作成するかもしれません。 このメソッドは政策ルールの状態/動作組の「状態」側面を表します。
- 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.
- 以前に条件付きに承認された承認決定にリソースのサービスかセットを遂行してください。 長期のlifecycle(トランザクションであることと対照的に)を持っているそれらの承認要求のために、このメソッドはAuthorized Sessionオブジェクトインスタンスに予約を動員します。 このメソッドは政策ルールの状態/動作組の「動作」側面を表します。
- Cancel a previously conditionally approved Authorization request.
This method releases any associated reservations for services or
resources.
- 以前に条件付きに承認されたAuthorization要求を中止してください。 このメソッドはサービスかリソースのどんな関連予約もリリースします。
- 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.
Authorization ServerオブジェクトインスタンスとしてAAAアプリケーションを構造化することに関する主要な動機はアプリケーション特有の承認決定論理とジェネリック承認決定論理を切り離すことです。 多くの場合、アプリケーションは全体でAAA問題と離婚できます、そして、責任を配属できるAAAはジェネリックを外部の規則に基礎づけました。AAA Server(考えは[5]で定義されるように信頼経営政策サーバのものと同様です。) これは中央倉庫でAAA方針を配布するセキュリティ管理者を容易にするでしょう。 AAA方針はすべてのAAAサーバによって制御されたアプリケーションの、そして、リソースの、そして、サービスのユーザの向こう側に一貫して申し込まれます。しかしながら、多くの問題ドメインには、アプリケーションに本質的なユニークな規則があると認められます。 これらの場合では、ジェネリックAAA ServerはUserの承認要求を関連Application Specific Moduleを参照しなければなりません。
3.3. Presentation Service Layer
3.3. プレゼンテーション・サービス層
The presentation service layer solves the data representation problems that are encountered when communicating peers exchange complex data structures or objects between their heterogeneous
プレゼンテーション・サービス層が交信している同輩が間に複雑なデータ構造かオブジェクトを交換すると行きあたられるデータ表現問題を解決する、それら、異種
de Laat, et al. Experimental [Page 16] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [16ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
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つの方法は既存の例を評価することです。 Generic Inter-ORBプロトコル(GIOP)とそのCommon Data Representation(CDR)はObject Management Group(OMG)産業共同体によって開発されたプレゼンテーション・サービス層のプロトコルです。 GIOPは共通オブジェクト・リクエスト・ブローカー・アーキテクチャ(CORBA)の中の1つのコンポーネントです。 多相系使用のときにリモートCORBAオブジェクトを呼び出すためにGIOPを実行する同輩Object Request Brokers(ORB)がメソッドを連結します。 GIOPはCommon Data Representation(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とその後継者は体系をコード化するプレゼンテーション・サービス層としてAttribute Value Pair(AVP)パラダイムを使用します。 そのようなアプローチは多能ですが、また、それも多くに裂かれるように臨時になって、ベンダーの特定の方言の傾向があります。 課された構造が全くないか、どのAVPsに関して規制を交渉するかメソッドは、AAAプロトコル実装か問題ドメインの向こう側に一貫した方法で結合されて、与えられた会話のために解釈されます。 ランタイムのときに、交信している同輩がAVPsの一般的な相互操作できるセットと交渉するのは、困難である場合があります。
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.
この落とし穴を避けるなら、プライマリプレゼンテーション・サービス層の責任は同輩にベースAuthorization Serverオブジェクトのクラスから両方のプレゼンテーション・サービス層の同輩が彼らのアプリケーションの特定の問題ドメインに実装した一般的に理解されている派生しているAuthorization Serverオブジェクトのクラスに向かって交渉させる能力です。 この交渉はAuthorization Serverオブジェクトクラス名のグローバルに登録されて、維持されたプレゼンテーション・サービス層の階層構造のための要件を含意します。
3.4. AAA Transaction/Session Management Service Layer
3.4. AAAトランザクション/セッション経営指導層
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 Transaction/セッションManagement(AAA-TSM)サービス層はAAA Serversの分散セットです。(Serversは異なった管理ドメインに通常住んでいます)。 彼らは以下の3つのサービスにまとめて、原因となります:
de Laat, et al. Experimental [Page 17] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [17ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
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:
承認--サービスかリソースに関するUserの要求を承諾するか、または否定するという承認決定をしてください。 ジェネリックは、より早く説明されたベースの方針エンジンが本書では承認決定関数を実行すると裁決します。 Userの要求が瞬時に起こって一時的であると、承認承認ははかないトランザクションとして扱われます。 承認承認がサービスかリソースの持続している消費を含意するなら、要求はAuthorized Sessionに変えられます。 Authorized Sessionの生涯の持続時間のために:
- 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サービス層はそれが特定のAuthorized Sessionであると実装しているそれらのAAA Serversのすべての向こう側にAuthorized Sessionの分散状態を同期させなければなりません。
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.
会計--それらのサービスかリソースの進行中の消費を表す承認決定と関連Authorized Session(もしあれば)に関するあらゆる関連課金情報を生成してください。
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概念は応用層サービスを求めるUser要求を承認するか、または不可とするために請求される1人以上のAAAのServer利害関係者のセットがあるということです。 AAA-TSMサービス層はUserの1人の利害関係者から次までの要求を発送します、承認決定をするようにすべて頼まれるまで必要な可決を蓄積して。
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
また、AAA Serversはこの承認審査方式の一部として認証(または、再認証)をUserにするかもしれません。 ルーティングの総合的な1人の利害関係者から別の利害関係者までの流れは[2]で開発された「プッシュ」、「牽引力」、または「エージェント」承認モデルの形を取るかもしれません。 しかしながら、原則として、利害関係者の中にAAA-TSM承認要求の任意のルーティング経路を持っているのは可能です。 最終承認がいったん受け取られているようになると、AAA-TSMサービス層は、それが必要とするそれらの利害関係者について皆、通知することによって、要求されたサービスを遂行します。
de Laat, et al. Experimental [Page 18] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [18ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
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).
確認、(すなわち、未定の予約をつけてください、トランザクションが公約する、) あるいはまた、同意リストの上のそれらの中のどんな利害関係者も承認が要求する拒否権をそうすることができます。 その場合、以前に、要求を承認して、確認を求めたすべての利害関係者が要求が否定されたと(すなわち、予約を取り消してください、そして、トランザクションロールバックをしてください)言われます。
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メッセージの中でContext州を埋め込むと、2つの利益が提供されます。 すぐに、まず最初に、AAA Serverのローカルの方針に関してメッセージを処理できて、これは、AAA Serverが総合的な承認決定の断片を完成するために追加AAA-TSMメッセージを同輩と交換する必要性を最小にするか、または全体で、避けます。 もう片方の利益はそれが完全に承認されるまでAAA Serverがそれがユーザの未定の要求に遂行する州の情報資源の量を最小にするということです。 これは、サービス不能攻撃から守るのを助けます。
One can envision many possible message elements that could be part of the Context State carried within an AAA-TSM request message:
人はAAA-TSM要求メッセージの中で運ばれたContext州の一部であるかもしれない多くの可能なメッセージ要素を思い描くことができます:
- 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サーバとSession生涯の間中そのその後のモニターはこのハンドルについて言及します。
- permission lists stating which AAA Servers are allowed to modify
which parts of the message.
- どのAAA Serversを述べる許可リストはメッセージのどの部分を変更できるか。
- 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).
- Userの承認要求の完全な承認を獲得するためにまだ訪問されていないAAAのServer利害関係者のリスト。 そのリストの各要素はユーザ承認要求がアプリケーションの特定のAuthorization Decision Function(ADF)によってどう評価されるはずであるかをコード化するプレゼンテーション層メッセージを含んでいます。
- the current position in the list of AAA Server stakeholders to be
visited.
- AAAのServer利害関係者のリストの訪問されるべき現在の見解。
de Laat, et al. Experimental [Page 19] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [19ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
- 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.
- 既に条件付きにUserの承認要求を承認しましたが、また、まだ要求を見ていない利害関係者から承認を終了する要求のときに彼らの承認を叙述したそれらの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.
- メッセージペイロード変更監査証跡であり、どのパーティーをつけるかと、変化はUserの承認要求条件に取り入れられました。
- 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メッセージの保全チェック。 その目的地同輩との基本的なReliable Secure Transport層の接続へこの機能を代表として派遣するかもしれません。
3.5. AAA-TSM Service Layer Program Interface Primitives
3.5. 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サービス層とその隣接しているプレゼンテーション・サービス層は1セットのプログラムインタフェース基関数を通ってそれらの境界の向こう側に交信します。 主要なデザイン目標は、より高い平らなAAAアプリケーションにかかわらず同じにこれらの基関数を保つことです、呼ぶことのできる「プラグイン」に類似しています。 2つのサービス層がそれらの州の情報を調整するのに原因となります。 この責任はそれらがともに制御して、モニターしている未定のAuthorization要求とAuthorizationセッションズのすべてを含んでいます。 AAA-TSM Service Access Point(SAP)と呼ばれる抽象的なオブジェクトを通してこれらの2つの層の間の初期接触があります。 これらの2つの層の間の特定のサービスインスタンスはAuthorized Sessionと呼ばれる抽象的なオブジェクトに実現されます。 プレゼンテーション・サービス層は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.
- プレゼンテーションエンドポイントアドレス識別子とその関連セットの属性をサービスアクセスポイントに示してください。
de Laat, et al. Experimental [Page 20] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [20ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
- 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.
- 別のプレゼンテーション層エンドポイントアドレスからプレゼンテーション層メッセージを受け取ってください。 Aは操作を受けます。メッセージが予想される特定の起因しているプレゼンテーション層エンドポイントアドレスを選択するかもしれないか、またはあらゆるプレゼンテーション層同輩からメッセージを受け取ってください。
- 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 Serverに部分的に承認します。(決定関数は賛意を述べる条件コードを返します)。
- 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.
- プレゼンテーション・サービス層は、進行中の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サービス層は、別のプレゼンテーション・サービス層の同輩がAuthorized Sessionを終えたことをプレゼンテーション・サービス層に通知します。
- Un-register a presentation service layer end point address.
- 不-プレゼンテーション・サービス層のエンドポイントアドレスを登録してください。
3.6. AAA-TSM Layer End Point Name Space
3.6. AAA-TSM層のエンドポイント名前スペース
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 ServerのReliable/安全なTransport層のエンドポイントアドレス
- 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承認要求通し番号(Userの承認要求が最初に受信されるAAA Serverによって生成されたユニークな長持ちする符号のない整数)。
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 Serverがリブートしても。
de Laat, et al. Experimental [Page 21] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [21ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
3.7. Protocol Stack Examples
3.7. プロトコル・スタックの例
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.
レイヤリングパラダイムで、そのアプリケーションのApplication Specific情報ユニットをコード化することの各アプリケーションに最も適切な構文を使用するのは可能になります。 このコード化はプレゼンテーション層で行われるでしょう。 同様に、応用層は各アプリケーションに特定の意味論を認識できます。 図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 | +----------------------------------------------------------------+
+------------++------------++-----------++-----------++----------+ | || アプリケーション|| 電子商取引|| 帯域幅|| ローミング| | AAA|| 特定|| インターネット|| ブローカー|| モバイルIP| | アプリケーション||オブジェクトのクラス|| 開いてください。||交差しているアドミン|| リモート| | サービス|| インタフェース|| 取り引き|| ドメイン|| アクセス| | 層||指定されます。|| プロトコル|| 巡査|| AVP| | || CORBA IDL|| (IOTP) || 拡大|| レキシコン| +------------++------------++-----------++-----------++----------+ | || CORBA||広げることができる|| 一般的|| 直径| |プレゼンテーション|| ジェネリック|| マークアップ|| 開いてください。|| または| | サービス|| 相互球|| 言語|| 方針|| 半径| | 層|| プロトコル|| (XML) ||Specificatn||属性| | || (GIOP) || || (巡査) ||値/組| +------------++------------++-----------++-----------++----------+ | AAA-TSMサービス層の適用業務プログラム・インタフェース(API)| +----------------------------------------------------------------+ | AAAトランザクション/セッション管理(AAA-TSM)サービス層| +----------------------------------------------------------------+ | 信頼できる安全なトランスポート層| +----------------------------------------------------------------+
Fig. 6 -- Possible AAA Protocol Stacks
図6--可能なAAAプロトコル・スタック
4. Security Considerations
4. セキュリティ問題
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メッセージの中で個人情報ユニットに適用できたデジタル署名の一部と定義されるべきであるよう提案します。 この粒状があるセキュリティが、[3] ただ一つのAAAメッセージが必要であるので、セキュリティ要件がセクション2.2.7で指定した終わりから終わりに間に合うのに必要です。
de Laat, et al. Experimental [Page 22] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [22ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
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.
アプリケーションSpecific情報(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.
アプリケーションSpecific Module(ASM)--AAAプロトコルメッセージのためのアプリケーションの特定の機能性を扱うジェネリックAAAサーバにプログラムインタフェースを実装するソフトウェア・モジュール。
Service Provider -- an organization which provides a service.
Providerを調整してください--サービスを提供する組織。
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.
ユーザホームOrganization(UHO)--UserにはUserを認証できて、リソースへのアクセスを認可できるかもしれない契約上の関係はある組織かサービス。
de Laat, et al. Experimental [Page 23] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [23ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
References
参照
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、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とL.とGrossとG.とde BruijnとB.とde LaatとD.とHoldregeとM.とD.スペンス、「AAA承認フレームワーク」、RFC2904、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とL.とGrossとG.とde BruijnとB.とde LaatとC.とHoldregeとM.とD.スペンス、「AAA承認アプリケーションの例」、RFC2905、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とL.とGrossとG.とde BruijnとB.とde LaatとC.とHoldregeとM.とD.スペンス、「AAA承認要件」、RFC2906、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インチ、RFC2704、1999年9月。」
Authors' Addresses
作者のアドレス
Cees T.A.M. de Laat Physics and Astronomy dept. Utrecht University Pincetonplein 5, 3584CC Utrecht Netherlands
Cees T.午前のde Laat PhysicsとAstronomy dept。 大学Pincetonplein5、ユトレヒト3584CCユトレヒトオランダ
Phone: +31 30 2534585 Phone: +31 30 2537555 EMail: delaat@phys.uu.nl
以下に電話をしてください。 +31 30 2534585は以下に電話をします。 +31 30 2537555はメールされます: delaat@phys.uu.nl
George M. Gross Lucent Technologies 184 Liberty Corner Road, m.s. LC2N-D13 Warren, NJ 07059 USA
ジョージM.Grossルーセントテクノロジーズ184リバティコーナーRoad、m.s. LC2N-D13ニュージャージー07059ウォレン(米国)
Phone: +1 908 580 4589 Fax: +1 908-580-4991 EMail: gmgross@lucent.com
以下に電話をしてください。 +1 908 580、4589Fax: +1 908-580-4991 メールしてください: gmgross@lucent.com
de Laat, et al. Experimental [Page 24] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [24ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
Leon Gommans Enterasys Networks EMEA Kerkplein 24 2841 XM Moordrecht The Netherlands
レオンGommans EnterasysはEMEA Kerkplein24 2841XM Moordrechtオランダをネットワークでつなぎます。
Phone: +31 182 379279
email: gommans@cabletron.com
or at University of Utrecht:
l.h.m.gommans@phys.uu.nl
以下に電話をしてください。 +31 182 379279 メール: 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
Vollbrechtが連結するジョンR.はInc.775技術ドライブ、アナーバー、200のスイートMI48108米国をネットワークでつなぎます。
Phone: +1 734 821 1205 Fax: +1 734 821 1235 EMail: jrv@interlinknetworks.com
以下に電話をしてください。 +1 734 821、1205Fax: +1 1235年の734 821メール: jrv@interlinknetworks.com
David W. Spence Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA
スペンスが連結するデヴィッドW.はInc.775技術ドライブ、アナーバー、200のスイートMI48108米国をネットワークでつなぎます。
Phone: +1 734 821 1203 Fax: +1 734 821 1235 EMail: dspence@interlinknetworks.com
以下に電話をしてください。 +1 734 821、1203Fax: +1 1235年の734 821メール: dspence@interlinknetworks.com
de Laat, et al. Experimental [Page 25] RFC 2903 Generic AAA Architecture August 2000
de Laat、他 [25ページ]実験的なRFC2903ジェネリックAAAアーキテクチャ2000年8月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
de Laat, et al. Experimental [Page 26]
de Laat、他 実験的[26ページ]
一覧
スポンサーリンク
