RFC2904 日本語訳
2904 AAA Authorization Framework. J. Vollbrecht, P. Calhoun, S.Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege,D. Spence. August 2000. (Format: TXT=78098 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Vollbrecht
Request for Comments: 2904 Interlink Networks, Inc.
Category: Informational P. Calhoun
Sun Microsystems, Inc.
S. Farrell
Baltimore Technologies
L. Gommans
Enterasys Networks EMEA
G. Gross
Lucent Technologies
B. de Bruijn
Interpay Nederland B.V.
C. de Laat
Utrecht University
M. Holdrege
ipVerse
D. Spence
Interlink Networks, Inc.
August 2000
Vollbrechtがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2904はネットワークInc.カテゴリを連結します: 情報のP.のHoldrege ipVerse D.スペンスInterlink Networks Inc.カルフーンサン・マイクロシステムズ・インクS.ファレルボルチモアTechnologies L.Gommans Enterasys Networks EMEA G.GrossルーセントテクノロジーズB.de Bruijn InterpayネーデルラントB.V.C.de Laatユトレヒト大学M.2000年8月
AAA Authorization Framework
AAA承認フレームワーク
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This memo serves as the base requirements for Authorization of Internet Resources and Services (AIRS). It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols.
このメモはインターネット資料とServices(AIRS)のAuthorizationのためのベース要件として機能します。 それは、インターネット資料の、そして、サービスの承認を理解するために建築フレームワークを提示して、承認プロトコルのために要件を引き出します。
Vollbrecht, et al. Informational [Page 1] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [1ページ]情報のRFC2904AAA承認フレームワーク2000年8月
Table of Contents
目次
1. Introduction ................................................ 2
2. Authorization Entities and Trust Relationships .............. 4
3. Message Sequences ........................................... 7
3.1. Single Domain Case ..................................... 7
3.1.1. The Agent Sequence .............................. 7
3.1.2. The Pull Sequence ............................... 8
3.1.3. The Push Sequence ............................... 9
3.2. Roaming ................................................ 10
3.3. Distributed Services ................................... 13
3.4. Combining Roaming and Distributed Services ............. 15
4. Relationship of Authorization and Policy .................... 16
4.1. Policy Retrieval ....................................... 16
4.2. Policy Evaluation ...................................... 17
4.3. Policy Enforcement ..................................... 17
4.4. Distributed Policy ..................................... 18
5. Use of Attribute Certificates ............................... 19
6. Resource Management ......................................... 22
6.1. Session Management ..................................... 23
6.2. The Resource Manager ................................... 24
7. AAA Message Forwarding and Delivery ......................... 25
8. End-to-End Security ......................................... 26
9. Streamlined Authorization Process ........................... 27
10. Summary of the Authorization Framework ..................... 28
11. Security Considerations .................................... 28
Glossary ....................................................... 29
References ..................................................... 31
Authors' Addresses ............................................. 32
Full Copyright Statement ....................................... 35
1. 序論… 2 2. 承認実体と信頼関係… 4 3. メッセージ系列… 7 3.1. 単一領域ケース… 7 3.1.1. エージェント系列… 7 3.1.2. 牽引力の系列… 8 3.1.3. プッシュ系列… 9 3.2. ローミング… 10 3.3. サービスを広げます… 13 3.4. ローミングと分配されたサービスを結合します… 15 4. 承認と方針の関係… 16 4.1. 方針検索… 16 4.2. 方針評価… 17 4.3. 方針実施… 17 4.4. 方針を分配します… 18 5. 属性証明書の使用… 19 6. リソース管理… 22 6.1. セッション管理… 23 6.2. 資源管理プログラム… 24 7. AAAメッセージ推進と配送… 25 8. 終わりから終わりへのセキュリティ… 26 9. 承認プロセスを流線型にします… 27 10. 承認フレームワークの概要… 28 11. セキュリティ問題… 28用語集… 29の参照箇所… 31人の作者のアドレス… 32 完全な著作権宣言文… 35
1. Introduction
1. 序論
This document is one of a series of three documents under consideration by the AAAarch RG dealing with the authorization requirements for AAA protocols. The three documents are:
このドキュメントはAAAプロトコルのための承認要件に対処するAAAarch RGによる考慮での一連の3通のドキュメントの1つです。 3通のドキュメントは以下の通りです。
AAA Authorization Framework (this document)
AAA Authorization Requirements [2]
AAA Authorization Application Examples [3]
AAA Authorization Framework(このドキュメント)AAA Authorization Requirements[2]AAA Authorization Application Examples[3]
There is a demonstrated need for a common scheme which covers all Internet services which offer Authorization. This common scheme will address various functional architectures which meet the requirements of basic services. We attempt to describe these architectures and functions as a basis for deriving requirements for an authorization protocol [2].
Authorizationを提供するすべてのインターネットのサービスをカバーする一般的な体系の示された必要があります。 この一般的な体系は基本サービスに関する必要条件を満たす様々な機能的な建築を扱うでしょう。 私たちは、承認プロトコル[2]のための要件を引き出す基礎としてこれらのアーキテクチャと機能を記述するのを試みます。
Vollbrecht, et al. Informational [Page 2] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [2ページ]情報のRFC2904AAA承認フレームワーク2000年8月
These architectures include Policy structures, Certificate Authorities, Resource Managers, Inter-Domain and Multi-Domain schemes, and Distributed Services. The requirements are for the expected use of Authorization services across these architectures.
これらのアーキテクチャはPolicy構造、Certificate Authorities、Resourceマネージャ、Inter-ドメインとMulti-ドメイン体系、およびDistributed Servicesを含んでいます。 要件はAuthorizationサービスの予想された使用のためにこれらのアーキテクチャのむこうにあります。
A representative set of applications that may use this architecture to support their authorization needs is presented in [3]. The examples in [3] show how this framework may be used to meet a wide variety of different authorization needs.
それらの承認が必要性であるとサポートするのにこのアーキテクチャを使用するかもしれない代表しているアプリケーションは[3]に提示されます。 [3]の例はこのフレームワークがさまざまな異なった承認需要を満たすのにどう使用されるかもしれないかを示しています。
We expect that this work may be extended in the future to a more comprehensive model and that the scheme described here will be incorporated into a framework that includes authentication, accounting and auditing. We have referenced a number of authorization sources, but also recognize that there may be some that we have missed and that should be included. Please notify one of the authors of any such oversight so it can be corrected in a future revision.
私たちは、この仕事が将来、より包括的なモデルに与えられるかもしれなくて、ここで説明された体系が認証(会計学と会計監査学)を含んでいるフレームワークに組み入れられると予想します。 私たちは多くの承認ソースに参照をつけましたが、私たちが逃した何かがあるかもしれなくて、それが含まれるべきであるとまた認めてください。 今後の改正でそれを修正できるようにあらゆるそのような見落としについて作者のひとりに通知してください。
In general, it is assumed that the parties who are participating in the authorization process have already gone through an authentication phase. The authentication method used by those parties is outside the scope of this document except to the extent that it influences the requirements found in a subsequent authorization process. Likewise, accounting requirements are outside the scope of this document other than recording accounting data or establishing trust relationships during an authorization that will facilitate a subsequent accounting phase.
一般に、承認プロセスに参加しているパーティーが既に認証フェーズに直面したと思われます。 このドキュメントの範囲の外にその後の承認プロセスで見つけられた要件に影響を及ぼすという範囲を除いて、それらのパーティーによって使用された認証方法があります。 同様に、その後の会計フェーズを容易にする承認の間、会計データを記録するか、または信頼関係を確立するのを除いたこのドキュメントの範囲の外に会計要件があります。
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作業部会のAuthorizationサブグループであったグループによって行われました。 MobileIPとNAS要件に焦点を合わせるためにAAAワーキンググループの特許を変えたとき、Authorizationサブグループによって始められた建築仕事を続けて、広げるためにIRTFの中でAAAarch Research Groupをチャーターしました。 このメモはサブグループによって作成された4の1つです。 このメモはAAAarch Research Groupの中のさらなる仕事のための出発点です。 それは、仕事がアーキテクチャか要件の決定的な記述ではなく、この領域で働いているAAAarchサブグループと他のものに利用可能になるように、それでも、処理中の作業であり、発行されます。
This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their negatives, in the way described in RFC 2119 [4].
このドキュメントはRFC2119[4]に述べられた方法で用語'MUST'、'SHOULD'、および'5月'、およびそれらのネガを使用します。
Vollbrecht, et al. Informational [Page 3] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [3ページ]情報のRFC2904AAA承認フレームワーク2000年8月
2. Authorization Entities and Trust Relationships
2. 承認実体と信頼関係
The following framework is being presented in order to provide a framework for discussing authorization requirements for a large number of applications. The intent is to provide some common vocabulary for the discussion. Terminology is introduced for basic elements in the authorization transaction and for concepts that appear to be common to all (or at least many) authorization proposals.
以下のフレームワークは、多くのアプリケーションのための承認要件について議論するのにフレームワークを提供するために提示されています。 意図は何らかの一般的なボキャブラリーを議論に提供することです。 用語は承認トランザクションにおける基本要素と承認提案に共通であるように見える概念のために紹介されます。
Figure 1, below, identifies the basic conceptual entities that may be participants in an authorization:
図1は以下で承認の関係者であるかもしれない基本的な概念的な実体を特定します:
1. A User who wants access to a service or resource.
1. サービスかリソースへのアクセスが欲しいUser。
2. A User Home Organization (UHO) that has an agreement with the user
and checks whether the user is allowed to obtain the requested
service or resource. This entity may carry information required
to authorize the User, which might not be known to the Service
Provider (such as a credit limit).
2. ユーザとの協定を持って、ユーザが要求されたサービスかリソースを得ることができるかどうかチェックするUserホームOrganization(UHO)。 この実体はService Provider(掛貸限度額などの)において知られていないかもしれないUserを認可するのに必要である情報を運ぶかもしれません。
3. A Service Provider's AAA Server which authorizes a service based
on an agreement with the User Home Organization without specific
knowledge about the individual User. This agreement may contain
elements that are not relevant to an individual user (e.g., the
total agreed bandwidth between the User Home Organization and the
Service Provider).
3. 個々のUserに関する特定の知識なしでUserホームOrganizationとの協定に基づくサービスを認可するService ProviderのAAA Server。 この協定は個々のユーザに関連していない要素を含むかもしれません(例えば、合計はUserホームOrganizationとService Providerの間の帯域幅に同意しました)。
4. A Service Provider's Service Equipment which provides the service
itself. This might, for example, be a NAS in dial service, or a
Router in the QoS service, or a print server in the Internet
Printing service.
4. サービス自体を提供するService ProviderのService Equipment。 例えば、これは、ダイヤルサービスにおけるNAS、QoSサービスにおけるRouter、またはインターネットPrintingサービスでプリント・サーバであるかもしれません。
Vollbrecht, et al. Informational [Page 4] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [4ページ]情報のRFC2904AAA承認フレームワーク2000年8月
+------+ +-------------------------+
| | | User Home Organization |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| |
| |
| |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
+------+ +-------------------------+ | | | ユーザホーム組織| | | | +-------------------+ | | | | | AAAサーバ| | | | | | | | | | | +-------------------+ | | | | | | | +-------------------------+ | | | | | | | ユーザ| +-------------------------+ | | | サービスプロバイダー| | | | +-------------------+ | | | | | AAAサーバ| | | | | | | | | | | +-------------------+ | | | | | | | | +-------------------+ | | | | | サービス| | | | | | 設備| | | | | +-------------------+ | | | | | +------+ +-------------------------+
Fig. 1 -- The Basic Authorization Entities
図1--基本認可実体
These entities will be referenced in the authorization requirements.
これらの実体は承認要件で参照をつけられるでしょう。
There may be bilateral agreements between pairs of organizations involved in an authorization transaction. Agreements between organizations may take the form of formal contracts or Service Level Agreements. Figure 2 uses double lines to show relationships that may exist between the User and the User Home Organization and between the User Home Organization and the Service Provider.
承認トランザクションにかかわる組の組織の間には、二国間条約があるかもしれません。 組織の間の協定は正式な契約かサービス・レベル・アグリーメントの形を取るかもしれません。 図2は、UserとUserホームOrganizationの間と、そして、UserホームOrganizationとService Providerの間に存在するかもしれない関係を示しているのに二重系列を使用します。
Vollbrecht, et al. Informational [Page 5] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [5ページ]情報のRFC2904AAA承認フレームワーク2000年8月
+------+ +-------------------------+
| | | User Home Organization |
| |======| +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| | ||
| | ||
| | ||
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
+------+ +-------------------------+ | | | ユーザホーム組織| | |======| +-------------------+ | | | | | AAAサーバ| | | | | | | | | | | +-------------------+ | | | | | | | +-------------------------+ | | || | | || | | || | ユーザ| +-------------------------+ | | | サービスプロバイダー| | | | +-------------------+ | | | | | AAAサーバ| | | | | | | | | | | +-------------------+ | | | | | | | | +-------------------+ | | | | | サービス| | | | | | 設備| | | | | +-------------------+ | | | | | +------+ +-------------------------+
Fig. 2 -- Service Agreements
図2--サービス契約
Authorization is based on these bilateral agreements between entities. Agreements may be chained, as shown in figure 2. The User has an agreement with the User Home Organization (e.g., the User may have access to the service between 9:00 a.m. and 11:00 a.m. daily). The User Home Organization has an agreement with the Service Provider (e.g., that all requests for access will be granted, except between 5:00 a.m. and 10:00 a.m. on Sunday). The fulfillment of the User's request depends on both agreements being honored.
承認は実体の間のこれらの二国間条約に基づいています。 2が中で計算するのが示されるように協定はチェーニングされるかもしれません。 Userには、UserホームOrganizationとの協定があります(例えば、Userは毎日午前9時0分と午前11時0分の間でサービスに近づく手段を持っているかもしれません)。 UserホームOrganizationには、Service Providerとの協定があります(例えば、それは、アクセスのために当然のことであるために望むようすべて要求します、午前5時と日曜日午前10時0分を除いて)。 Userの要求の遂行は両方の光栄に思っている協定によります。
Note that these agreements may be implemented by hand configuration or by evaluation of Policy data stored in a Policy database. The point is that there must be a set of known rules in place between entities in order for authorization transactions to be executed.
これらの協定が手の構成かPolicyデータベースに保存されたPolicyデータの評価で履行されるかもしれないことに注意してください。 ポイントは承認トランザクションが実行されるために実体の間には、1セットの知られている規則が適所にあるに違いないということです。
Trust is necessary to allow each entity to "know" that the policy it is authorizing is correct. This is a business issue as well as a protocol issue. Trust is often established through third party authentication servers (such as Kerberos), via a certificate authority, by configuring shared secrets or passwords, or by sharing a common facility (such as a connecting wire between processors). These "static" trust relationships are necessary for authorization
信頼が、それが認可している方針が正しいのを「知る」ために各実体を許容するのに必要です。 これはプロトコル問題と同様にビジネス問題です。 信頼は第三者認証サーバ(ケルベロスなどの)を通してしばしば確立されます、共有秘密キーかパスワードを構成するか、または一般的な施設を共有するのによる認証局(プロセッサの間の補助母線などの)で。 これらの「静的な」信頼関係が承認に必要です。
Vollbrecht, et al. Informational [Page 6] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [6ページ]情報のRFC2904AAA承認フレームワーク2000年8月
transactions to take place. Static trust relationships are used in an authorization sequence to establish a "dynamic" relationship between the User and the Service Equipment. Several possible authorization sequences are possible, each of which use the static trust "chain" to have the user first be approved by the User Home Organization, and then have the Service Provider accept the request based on its trust of the User Home Organization.
行われるトランザクション。 静的な信頼関係は、UserとService Equipmentとの「ダイナミックな」関係を証明するのに承認系列に使用されます。 いくつかの可能な承認系列が可能です、どれがユーザがいるのに静的な信頼「チェーン」を使用するかに関する1番目でUserホームOrganizationによって承認されて、Service Providerが次にUserホームOrganizationの信頼に基づいて要請を受け入れるそれぞれ。
3. Message Sequences
3. メッセージ系列
In general, the User Home Organization and the Service Provider are different entities or different "administrative domains". In the simplest case, however, the User Home Organization and the Service Provider may be combined as a single entity. This case will be used to describe three authorization sequences possible with the simple case.
一般に、UserホームOrganizationとService Providerは異なった実体か異なった「管理ドメイン」です。 しかしながら、最も簡単な場合では、UserホームOrganizationとService Providerは単一体として結合されるかもしれません。 本件は、簡単な場合で可能な3つの承認系列について説明するのに使用されるでしょう。
In following sections these concepts will be applied to more complicated cases involving separate User Home Organization and Service Provider entities (as in roaming) and multiple Service Providers each with their own AAA Servers and Service Equipment (as in distributed services).
以下の章で、これらの概念はそれら自身のAAA ServersとService Equipmentと共にそれぞれ別々のUserホームOrganizationにかかわるより複雑なケース、Service Provider実体(ローミングのように)、および複数のService Providersに適用されるでしょう(分配されたサービスのように)。
3.1. Single Domain Case
3.1. 単一領域ケース
This case includes the User, the Service Provider's AAA Server, and the Service Provider's Service Equipment. Examples of this case include a NAS supported by a standalone RADIUS server, or a QoS Router supported by a local bandwidth broker.
本件はUser、Service ProviderのAAA Server、およびService ProviderのService Equipmentを含んでいます。 本件に関する例はスタンドアロンRADIUSサーバによってサポートされたNAS、または地元の帯域幅ブローカーによってサポートされたQoS Routerを含んでいます。
The sequences considered in the following figures are the "agent", "pull", and "push" sequences for the single domain case.
以下の数字で考えられた系列は、単一領域ケースのために「エージェント」であり、「引い」て、系列を「押します」。
3.1.1. The Agent Sequence
3.1.1. エージェント系列
In the agent sequence (see figure 3), the Service Provider AAA Server functions as an agent between the User and the service itself. The AAA Server receives a request from the User and forwards authorization and possibly configuration information to the Service Equipment. In this model, the User sends a request to the Service Provider's AAA Server (1), which will apply a policy associated with the User and the particular service being requested. The AAA Server sends a request to the Service Equipment, and the Service Equipment sets up whatever is requested (2). The Service Equipment then responds to the AAA Server acknowledging that it has set up the Service for the user (3). The AAA Server replies to the User telling it that the Service is set up (4).
エージェント系列(3が計算するのがわかる)では、Service Provider AAA ServerはUserとサービス自体の間のエージェントとして機能します。 AAA ServerはUserから要求を受け取って、承認とことによると設定情報をService Equipmentに転送します。 このモデルでは、UserはService ProviderのAAA Server(1)に要求を送ります。(Serverは要求されているUserと特定のサービスに関連している方針を適用するでしょう)。 AAA Serverは要求をService Equipmentに送ります、そして、何が要求されても、Service Equipmentはセットアップします。(2)。 ユーザ(3)のためにServiceをセットアップしたと認めながら、そしてService EquipmentはAAA Serverに応じます。 AAA ServerはServiceが(4)に用意ができているとそれに言うUserに答えます。
Vollbrecht, et al. Informational [Page 7] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [7ページ]情報のRFC2904AAA承認フレームワーク2000年8月
Depending on the nature of the service, further communication may take place between the User and the Service Equipment. For this to occur, there needs to be a binding between the User and the authorized service. This requires further study.
サービスの本質によって、さらなるコミュニケーションはUserとService Equipmentの間の場所を取るかもしれません。 これが起こるように、結合がUserと認可されたサービスの間であるのが必要です。 これはさらなる研究を必要とします。
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 4 | +-------------------+ |
| User | | | /|\ |
| | | |2 |3 |
| | | \|/ | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
+------+ | |
+-------------------------+
+-------------------------+ +------+ | サービスプロバイダー| | | 1 | +-------------------+ | | |------+->| AAAサーバ| | | | <、-、-、-、--+--| | | | | 4 | +-------------------+ | | ユーザ| | | /|\ | | | | |2 |3 | | | | \|/ | | | | | +-------------------+ | | | | | サービス| | | | | | 設備| | | | | +-------------------+ | +------+ | | +-------------------------+
Fig. 3 -- Agent Sequence
図3--エージェント系列
Example: A regular user may ask for 1 Mb/s bandwidth (1). The bandwidth broker (AAA Server) tells the router (Service Equipment) to set this user into the 1Mb/s "queue" (2). The router responds that it has done so (3), and the bandwidth broker tells the User the bandwidth is set up (4).
例: 愛用者は1Mb/sの帯域幅(1)を求めるかもしれません。 帯域幅ブローカー(AAA Server)は、1Mb/s「待ち行列」(2)にこのユーザを設定するようにルータ(サービスEquipment)に言います。 ルータは、そう(3)をしたと応答します、そして、帯域幅ブローカーは帯域幅が(4)に設定されるとUserに言います。
3.1.2. The Pull Sequence
3.1.2. 牽引力の系列
The pull sequence (figure 4) is what is typically used in the Dialin application, in the Mobile-IP proposal, and in some QoS proposals. The User sends a request to the Service Equipment (1), which forwards it to the Service Provider's AAA Server (2), which evaluates the request and returns an appropriate response to the Service Equipment (3), which sets up the service and tells the User it is ready (4).
牽引力の系列(4について計算する)はDialinアプリケーション、モバイルIP提案、およびいくつかのQoS提案に通常使用されることです。 (Service EquipmentはService ProviderのAAA Server(2)にそれを送ります)。(Serverは要求を評価します)。UserはService Equipment(1)に要求を送って、Service Equipment(3)への適切な応答を返します。Service Equipmentはサービスをセットアップして、それが持ち合わせの(4)であるとUserに言います。
Vollbrecht, et al. Informational [Page 8] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [8ページ]情報のRFC2904AAA承認フレームワーク2000年8月
+-------------------------+
+------+ | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| User | | /|\ | |
| | | |2 |3 |
| | | | \|/ |
| | 1 | +-------------------+ |
| |------+->| Service | |
| |<-----+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
+-------------------------+ +------+ | サービスプロバイダー| | | | +-------------------+ | | | | | AAAサーバ| | | | | | | | | | | +-------------------+ | | ユーザ| | /|\ | | | | | |2 |3 | | | | | \|/ | | | 1 | +-------------------+ | | |------+->| サービス| | | | <、-、-、-、--+--| 設備| | | | 4 | +-------------------+ | +------+ | | +-------------------------+
Fig. 4 -- Pull Sequence
図4--系列を引いてください。
3.1.3. The Push Sequence
3.1.3. プッシュ系列
The push sequence (figure 5) requires that the User get from the Service Provider's AAA Server a ticket or certificate verifying that it is o.k. for the User to have access to the service (1,2). The User includes the ticket in the request (3) to the Service Equipment. The Service Equipment uses the ticket to verify that the request is approved by the Service Provider's AAA Server. The Service Equipment then sends an o.k. to the User (4).
プッシュ系列(5について計算する)は、Userがチケットか証明書にService ProviderのAAA ServerからUserがサービス(1、2)に近づく手段を持っているのが、間違いないことを確かめさせるのを必要とします。 Userは要求(3)でService Equipmentにチケットを含めます。 Service Equipmentは、要求がService ProviderのAAA Serverによって承認されることを確かめるのにチケットを使用します。次に、Service EquipmentはUser(4)にOKを送ります。
The ticket the user gets from the Service Provider's AAA Server will typically have some time limit on it. It may contain an indication of service location, and in some applications, it might be used for more than one request.
ユーザがService ProviderのAAA Serverから手に入れるチケットはそれに何らかのタイムリミットを通常持つでしょう。 それはサービス位置のしるしを含むかもしれません、そして、使用目的によっては、1つ以上の要求に使用されるかもしれません。
In the push sequence the communication between the AAA Server and the Service Equipment is relayed through the User rather than directly between themselves.
プッシュ系列では、AAA ServerとService Equipmentとのコミュニケーションは自分たちの直接間でというよりむしろUserを通してリレーされます。
Vollbrecht, et al. Informational [Page 9] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [9ページ]情報のRFC2904AAA承認フレームワーク2000年8月
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 2 | +-------------------+ |
| User | | |
| | | |
| | | |
| | 3 | +-------------------+ |
| |------+->| Service | |
| |<-----+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
+-------------------------+ +------+ | サービスプロバイダー| | | 1 | +-------------------+ | | |------+->| AAAサーバ| | | | <、-、-、-、--+--| | | | | 2 | +-------------------+ | | ユーザ| | | | | | | | | | | | | 3 | +-------------------+ | | |------+->| サービス| | | | <、-、-、-、--+--| 設備| | | | 4 | +-------------------+ | +------+ | | +-------------------------+
Fig. 5 -- Push Sequence
図5--系列を押してください。
3.2. Roaming -- the User Home Organization is not the Service Provider
3.2. ローミング--UserホームOrganizationはService Providerではありません。
In many interesting situations, the organization that authorizes and authenticates the User is different from the organization providing the service. This situation has been explored in the Roaming Operations (roamops) Working Group. For purposes of this discussion, any situation in which the User Home Organization is different from the Service Provider is considered to be roaming.
多くのおもしろい状況で、Userを認可して、認証する組織はサービスを提供する組織と異なっています。 Roaming Operations(roamops)作業部会でこの状況について調査してあります。 この議論の目的のために、UserホームOrganizationがService Providerと異なっているどんな状況も移動していると考えられます。
Examples of roaming include an ISP selling dialin ports to other organizations or a Mobile-IP provider allowing access to a user from another domain.
ローミングに関する例はdialinポートを他の組織に販売するISPか別のドメインからユーザへのアクセスを許すモバイルIPプロバイダーを含んでいます。
The same agent, pull and push sequences are possible with roaming. If the Service Provider's AAA Server and the Service Equipment are grouped as a logical entity for purposes of description, then the following figures illustrate these cases.
同じエージェント、牽引力、およびプッシュ系列はローミングで可能です。 Service ProviderのAAA ServerとService Equipmentが記述の目的のための論理的な実体として分類されるなら、以下の数字はこれらのケースを例証します。
Vollbrecht, et al. Informational [Page 10] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [10ページ]情報のRFC2904AAA承認フレームワーク2000年8月
+------+ +-------------------------+
| | 1 | User Home Organization |
| |----->| +-------------------+ |
| | | | AAA Server | |
| |<-----| | | |
| | 4 | +-------------------+ |
| | | |
| | +-------------------------+
| | | /|\
| | |2 |3
| | \|/ |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
+------+ +-------------------------+ | | 1 | ユーザホーム組織| | |、-、-、-、--、>| +-------------------+ | | | | | AAAサーバ| | | | <、-、-、-、--、|、|、|、|、|、| 4 | +-------------------+ | | | | | | | +-------------------------+ | | | /|\ | | |2 |3 | | \|/ | | ユーザ| +-------------------------+ | | | サービスプロバイダー| | | | +-------------------+ | | | | | AAAサーバ| | | | | | | | | | | +-------------------+ | | | | | | | | +-------------------+ | | | | | サービス| | | | | | 設備| | | | | +-------------------+ | | | | | +------+ +-------------------------+
Fig. 6 -- Roaming Agent Sequence
図6--ローミングエージェント系列
Vollbrecht, et al. Informational [Page 11] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [11ページ]情報のRFC2904AAA承認フレームワーク2000年8月
+------+ +-------------------------+
| | | User Home Organization |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| | /|\ |
| | |2 |3
| | | \|/
| | +-------------------------+
| | | Service Provider |
| User | | +-------------------+ |
| | | | AAA Server | |
| | 1 | | | |
| |----->| +-------------------+ |
| | | |
| |<-----| +-------------------+ |
| | 4 | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
+------+ +-------------------------+ | | | ユーザホーム組織| | | | +-------------------+ | | | | | AAAサーバ| | | | | | | | | | | +-------------------+ | | | | | | | +-------------------------+ | | /|\ | | | |2 |3 | | | \|/ | | +-------------------------+ | | | サービスプロバイダー| | ユーザ| | +-------------------+ | | | | | AAAサーバ| | | | 1 | | | | | |、-、-、-、--、>| +-------------------+ | | | | | | | <、-、-、-、--、| +-------------------+ | | | 4 | | サービス| | | | | | 設備| | | | | +-------------------+ | | | | | +------+ +-------------------------+
Fig. 7 -- Roaming Pull Sequence
図7--ローミング牽引力の系列
Vollbrecht, et al. Informational [Page 12] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [12ページ]情報のRFC2904AAA承認フレームワーク2000年8月
+------+ +-------------------------+
| | 1 | User Home Organization |
| |----->| +-------------------+ |
| | | | AAA Server | |
| |<-----| | | |
| | 2 | +-------------------+ |
| | | |
| | +-------------------------+
| |
| |
| |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | 3 | | | |
| |----->| +-------------------+ |
| | | |
| |<-----| +-------------------+ |
| | 4 | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
+------+ +-------------------------+ | | 1 | ユーザホーム組織| | |、-、-、-、--、>| +-------------------+ | | | | | AAAサーバ| | | | <、-、-、-、--、|、|、|、|、|、| 2 | +-------------------+ | | | | | | | +-------------------------+ | | | | | | | ユーザ| +-------------------------+ | | | サービスプロバイダー| | | | +-------------------+ | | | | | AAAサーバ| | | | 3 | | | | | |、-、-、-、--、>| +-------------------+ | | | | | | | <、-、-、-、--、| +-------------------+ | | | 4 | | サービス| | | | | | 設備| | | | | +-------------------+ | | | | | +------+ +-------------------------+
Fig. 8 -- Roaming Push Sequence
図8--ローミングプッシュ系列
3.3. Distributed Services
3.3. 分配されたサービス
To provide a complete service to a user, offerings from several service providers may need to be combined. An example would be a user who requires a QoS service for a session that crosses multiple ISPs. Any service that is provided by more than one Service Provider acting in concert is a distributed service. Figure 9 illustrates distributed services.
ユーザに対する完全なサービスを提供するために、いくつかのサービスプロバイダーからの提供は、結合される必要があるかもしれません。 例は複数のISPに交差するセッションのためにQoSサービスを必要とするユーザでしょう。 一致した行動を取る1Service Providerによって提供されるどんなサービスも分配されたサービスです。 図9は分配されたサービスを例証します。
Vollbrecht, et al. Informational [Page 13] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [13ページ]情報のRFC2904AAA承認フレームワーク2000年8月
+-------------------+ +-------------------+
+------+ | Org1 | | Org2 |
| | | +-------------+ | | +-------------+ |
| | | | AAA Server | | | | AAA Server | |
| | | | | | | | | |
| | | +-------------+ | | +-------------+ |
| User |======| |======| |
| | | +-------------+ | | +-------------+ |
| | | | Service | | | | Service | |
| | | | Equipment | | | | Equipment | |
| | | +-------------+ | | +-------------+ |
+------+ | | | |
+-------------------+ +-------------------+
+-------------------+ +-------------------+ +------+ | Org1| | Org2| | | | +-------------+ | | +-------------+ | | | | | AAAサーバ| | | | AAAサーバ| | | | | | | | | | | | | | | +-------------+ | | +-------------+ | | ユーザ|======| |======| | | | | +-------------+ | | +-------------+ | | | | | サービス| | | | サービス| | | | | | 設備| | | | 設備| | | | | +-------------+ | | +-------------+ | +------+ | | | | +-------------------+ +-------------------+
Fig. 9 -- Distributed Services
図9--分配されたサービス
The agreements between entities in figure 9 imply that the request from the User will be authenticated and authorized by the first organization, then forwarded to the second organization. Note that the sequence between User and Org1 may be different than between Org1 and Org2. The first might use a pull sequence, and the second might use an agent sequence. This example is illustrated in figure 10.
9図の実体の間の協定は、Userからの要求が最初の組織によって認証されて、認可されて、次に、2番目の組織に転送されるのを含意します。 UserとOrg1の間の系列がOrg1とOrg2より異なるかもしれないことに注意してください。 1番目は牽引力の系列を使用するかもしれません、そして、2番目はエージェント系列を使用するかもしれません。 この例は例証されて、10が中で計算するということです。
+-------------------+ +-------------------+
+------+ | Org1 | | Org2 |
| | | +-------------+ | 3 | +-------------+ |
| | | | AAA Server |--+------+->| AAA Server | |
| | | | |<-+------+--| | |
| | | +-------------+ | 6 | +-------------+ |
| User | | /|\ | | | | /|\ |
| | | |2 |7 | | |4 |5 |
| | | | \|/ | | \|/ | |
| | 1 | +-------------+ | | +-------------+ |
| |------+->| Service | | | | Service | |
| |<-----+--| Equipment | | | | Equipment | |
| | 8 | +-------------+ | | +-------------+ |
+------+ | | | |
+-------------------+ +-------------------+
+-------------------+ +-------------------+ +------+ | Org1| | Org2| | | | +-------------+ | 3 | +-------------+ | | | | | AAAサーバ|--+------+->| AAAサーバ| | | | | | | <、-+------+--| | | | | | +-------------+ | 6 | +-------------+ | | ユーザ| | /|\ | | | | /|\ | | | | |2 |7 | | |4 |5 | | | | | \|/ | | \|/ | | | | 1 | +-------------+ | | +-------------+ | | |------+->| サービス| | | | サービス| | | | <、-、-、-、--+--| 設備| | | | 設備| | | | 8 | +-------------+ | | +-------------+ | +------+ | | | | +-------------------+ +-------------------+
Fig. 10 -- A Possible Distributed Sequence
図10--可能な分散系列
There are a number of other ways that authorization sequences for distributed services can be set up. For example, it is possible that, in order to reduce delay time in setting up a session, Org1 could send a response to the user before receiving a verification that Org2 has authorized the service. In that case Org1 would need to be able to revoke the authorization sent earlier if Org2 does not send the authorization in some amount of time.
分配されたサービスのための承認系列をセットアップできる他の多くの方法があります。 例えば、Org2がサービスを認可したのは、検証を受ける前にOrg1がセッションをセットアップしながら遅延時間を下げるために応答をユーザに送ることができたのが可能です。 その場合、Org1は、いつかの時間のOrg2が承認を送らないなら、より早く送られた承認を取り消すことができる必要があるでしょう。
Vollbrecht, et al. Informational [Page 14] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [14ページ]情報のRFC2904AAA承認フレームワーク2000年8月
3.4. Combining Roaming and Distributed Services
3.4. ローミングと分配されたサービスを結合します。
Figure 11 shows a combination of Roaming and Distributed Services. Contract and trust relationships may be set up in number of ways, depending on a variety of factors, especially the business model.
図11はRoamingとDistributed Servicesの組み合わせを示しています。 契約してください。そうすれば、信頼関係は方法の数でセットアップされてもよいです、さまざまな要素(特にビジネスモデル)によって
+------+ +-------------------+ +-------------------+ | | | User Home Org | | SuperOrg | | | | +-------------+ | | +-------------+ | | | | | AAA Server | | | | AAA Server | | | | | | | | | | | | | | | +-------------+ | | +-------------+ | | | | | | | | | +-------------------+ +-------------------+ | | | | | | +-------------------+ +-------------------+ | User | | Org1 | | Org2 | | | | +-------------+ | | +-------------+ | | | | | AAA Server | | | | AAA Server | | | | | | | | | | | | | | | +-------------+ | | +-------------+ | | | | | | | | | | +-------------+ | | +-------------+ | | | | | Service | | | | Service | | | | | | Equipment | | | | Equipment | | | | | +-------------+ | | +-------------+ | | | | | | | +------+ +-------------------+ +-------------------+
+------+ +-------------------+ +-------------------+ | | | ユーザホームOrg| | SuperOrg| | | | +-------------+ | | +-------------+ | | | | | AAAサーバ| | | | AAAサーバ| | | | | | | | | | | | | | | +-------------+ | | +-------------+ | | | | | | | | | +-------------------+ +-------------------+ | | | | | | +-------------------+ +-------------------+ | ユーザ| | Org1| | Org2| | | | +-------------+ | | +-------------+ | | | | | AAAサーバ| | | | AAAサーバ| | | | | | | | | | | | | | | +-------------+ | | +-------------+ | | | | | | | | | | +-------------+ | | +-------------+ | | | | | サービス| | | | サービス| | | | | | 設備| | | | 設備| | | | | +-------------+ | | +-------------+ | | | | | | | +------+ +-------------------+ +-------------------+
Fig. 11 -- Roaming and Distributed Services
図11--ローミングと分配されたサービス
New entities that combine or add capabilities can be created to meet business needs. In figure 11, one such possibility, a SuperOrg entity is shown. The idea is that this entity would provide authentication and authorization for organizations that are providing services to end-users. It could be considered to be a wholesaler or broker. While not all authorization will require having a broker, authorization protocols should allow such entities to be created to meet legitimate requirements.
ビジネス需要を満たすために能力を結合するか、または加える新しい実体は作成できます。 SuperOrg実体は11、そのような可能性の1つが中で計算するのが示されます。 考えはこの実体がエンドユーザに対するサービスを提供している組織に認証と承認を提供するだろうということです。 卸売業者かブローカーであることが考えることができました。 すべての承認が、ブローカーを持っているのを必要とするというわけではない間、承認プロトコルは、そのような実体が正当な要求を満たすために作成されるのを許容するべきです。
Having considered the basic players and how they interact, we will now consider different ways that authorization data may be stored in the network.
基本的なプレーヤーと彼らがどう相互作用するかを考えたので、私たちは現在、ネットワークで保存されていた状態で承認データがあるかもしれない異なった道を考えるつもりです。
Vollbrecht, et al. Informational [Page 15] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [15ページ]情報のRFC2904AAA承認フレームワーク2000年8月
4. Relationship of Authorization and Policy
4. 承認と方針の関係
The Policy Framework (policy) Working Group is seeking to provide a framework to represent, manage, and share policies and policy information in a vendor-independent, interoperable, scalable manner. [5],[6],[7]. This section explores the relationship of policy and authorization and sets the stage for defining protocol requirements for supporting policy when included as part of multi-domain authorization. The work presented here builds on the policy framework, extending it to support policy across multiple domains.
Policy Framework(方針)作業部会は、ベンダーから独立していて、共同利用できて、スケーラブルな方法による方針と方針情報を表して、管理して、共有するためにフレームワークを提供しようとしています。 [5],[6],[7]. マルチドメイン承認の一部として含まれていると、このセクションは、方針と承認の関係について調査して、方針をサポートするためのプロトコル要件を定義するために舞台装置をセットします。 複数のドメインの向こう側に方針をサポートするためにそれを広げていて、ここに提示された仕事は方針フレームワークに建てられます。
One view of an authorization is that it is the result of evaluating policies of each organization that has an interest in the authorization decision. In this document the assumption is that each administration may have policies which may be indexed by user, by service, or by other attributes of the request. The policies of each administration are defined independently of other administrations.
承認の1つの視点はそれが承認決定に関心を持っているそれぞれの組織の方針を評価するという結果であるということです。 本書では仮定は各管理にはユーザ、サービス、または要求の他の属性によって索引をつけられるかもしれない方針があるかもしれないということです。 それぞれの管理の方針は他の政権の如何にかかわらず定義されます。
Each independent policy must be 1) retrieved, 2) evaluated, and 3) enforced.
それぞれの独立している方針は、検索された1と)、評価された2と)、励行される3であるに違いありません)。
4.1. Policy Retrieval
4.1. 方針検索
Policy definitions are maintained and stored in a policy repository [5] by (or on behalf of) the organization that requires them. The Policy Framework WG is working on a way to describe policy [7]. Other implementations describe policy as a set of ACL lists. Policy definitions must be retrieved in order to be evaluated and enforced. Policy Definitions can be indexed by requester, by service attribute, or by some other key. The organization requiring the policy is also responsible for determining which policy is to be applied to a specific authorization request.
を代表してまたは、方針定義が方針倉庫に維持されて、保存される、()、それらを必要とする組織。 Policy Framework WGは方針[7]を説明する方法に取り組んでいます。 他の実装は1セットのACLリストとして方針を記述します。 評価されて、実施されるために方針定義を検索しなければなりません。 リクエスタ、サービス属性、またはある他のキーは方針Definitionsに索引をつけることができます。 また、どの方針が特定の承認要求に適用されるかことであるかを決定するのに方針を必要とする組織も責任があります。
Policy retrieval is typically done by the administration that defines the policy or by an agent acting for that administration. Thus a policy defining the times of day that a particular User is allowed to connect to the network is maintained and retrieved by the User Organization. A policy defining a time that ports will be unusable because of maintenance is maintained and retrieved by the Service Provider.
方針を定義する管理かその管理の代理をするエージェントが方針検索を通常完了しています。 したがって、特定のUserがネットワークに接続できる日の回を定義する方針は、User Organizationによって維持されて、検索されます。 ポートがメインテナンスで使用不可能になる時間を定義する方針は、Service Providerによって維持されて、検索されます。
Note that some implementation may choose to have the Service Provider retrieve a policy from the User Home Organization using a distributed directory access protocol. This may be appropriate in some cases, but is not a general solution. To understand why, suppose the remote administration and the home administration communicate via a broker which proxies their communications. In this case the remote and home
何らかの実装が、Service ProviderにUserホームOrganizationから分配されたディレクトリアクセス・プロトコルを使用することで方針を検索させるのを選ぶかもしれないことに注意してください。 これは、いくつかの場合適切であるかもしれませんが、一般解ではありません。 理由を理解するために、リモート管理と内政がブローカーを通してそれのプロキシを伝えると仮定してください。彼らのコミュニケーション。 この場合リモートとホーム
Vollbrecht, et al. Informational [Page 16] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [16ページ]情報のRFC2904AAA承認フレームワーク2000年8月
administrations have no prior relationship, and therefore the home administration directory is unlikely to be open for access by the remote administration and vice versa.
政権には、どんな先の関係もありません、そして、したがって、内政ディレクトリをリモート管理によるアクセスにおいて逆もまた同様に開かせそうにはありません。
4.2. Policy Evaluation
4.2. 政策評価
Evaluation of policy requires access to information referenced by the policy. Often the information required is not available in the administration where the policy is retrieved. For example, checking that a user is allowed to login at the current time can readily be done by the User Home Organization because the User Home Organization has access to current time. But authorizing a user requiring a 2Mb/s path with less than 4 hops requires information available at a Service Provider and not directly available to the UHO, so the UHO must either 1) have a way to query a remote administration for the needed information or 2) forward the policy to the remote administration and have the remote administration do the actual evaluation or 3) attempt somehow to "shadow" the authoritative source of the information (e.g by having the Service Provider send updates to the UHO).
方針の評価は方針で参照をつけられる情報入手を必要とします。 しばしば、必要である情報は方針が検索されるところで管理で利用可能であるというわけではありません。 例えば、UserホームOrganizationが現在の時間にアクセスを持っているので、UserホームOrganizationは、ユーザが現在の時間にログインできるのを容易にチェックできます。 したがって、しかし、ユーザに権限を与えるのが4つのホップがService Providerで利用可能な情報を必要とするよりそれほど、そして、直接でないUHOに利用可能であるのがある2Mb/sの経路を必要とする場合、UHOは1が、)必要な情報か2のために)リモート管理について質問する方法でリモート管理に方針を送って、リモート管理が情報(Service ProviderにアップデートをUHOに送らせるのによるe.g)の権威筋を「影でおおう」ためにどうにか実際の評価か3)試みをするのを持っているどちらかを必要としなければなりません。
Applications might support either 1) or 2), and a general authorization protocol must allow both. Case 3) is not considered further as shadowing seems too "expensive" to be supported by an AAA protocol.
アプリケーションは1か)2を)サポートするかもしれません、そして、一般的な承認プロトコルは両方を許容しなければなりません。 より遠くに、シャドウイングが「高価に」見え過ぎるとしてAAAプロトコルによってケース3)がサポートされると考えられません。
An example of case 1 is when a Service Provider forwards a request to a UHO which includes a query for the clearance code of the User. The Service Provider policy includes reference to the clearance code and the information in the reply is used as input to that policy.
ケース1に関する例はService ProviderがUserのクリアランスコードのための質問を含んでいるUHOに要求を転送する時です。 Service Provider方針はクリアランスコードの指示するものを含んでいます、そして、回答における情報はその方針に入力されるように使用されています。
An example of case 2 is when the UHO approves an authorization conditional on the Service Provider confirming that there is currently a specific resource available for its use. The UHO includes the "policy" along with a conditional authorization to the Service Provider.
ケース2に関する例はUHOが使用に利用可能な特定のリソースが現在あると確認するService Providerに依存している承認を承認する時です。 UHOは条件付きの承認に伴う「方針」をService Providerに含めます。
4.3. Policy Enforcement
4.3. 方針実施
Policy Enforcement is typically done by the Service Provider on the Service Equipment. The Service Equipment is equivalent to the Policy Target described in the Policy Framework [5]. Thus a NAS may enforce destination IP address limits via "filters" and a Router may enforce QoS restrictions on incoming packets. The protocol that sends the information between the Service Equipment and the Service Provider AAA Server may be specific to the Service Equipment, but it seems that the requirements are not different in kind from what is required between other AAA servers.
Service Equipmentの上のService Providerは方針Enforcementを通常完了しています。 Service EquipmentはPolicy Framework[5]で説明されたPolicy Targetに同等です。 したがって、NASは「フィルタ」を通して目的地IPアドレス限界を実施するかもしれません、そして、RouterはQoS制限に入って来るパケットに押しつけるかもしれません。 Service EquipmentとService Provider AAA Serverの間に情報を送るプロトコルはService Equipmentに特定であるかもしれませんが、要件が他のAAAサーバの間で必要であることと本質的に異なっていないように思えます。
Vollbrecht, et al. Informational [Page 17] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [17ページ]情報のRFC2904AAA承認フレームワーク2000年8月
In particular, an AAA Server could send a "policy" to the Service Equipment stating what the equipment should do under various situations. The Service equipment should either set up to "enforce" the policy or reject the request.
特に、AAA Serverは設備が様々な状況の下でするはずであることを述べるService Equipmentに「方針」を送ることができました。 Service設備は、方針を「実施する」か、または要求を拒絶するためにセットアップされるはずです。
The AAA Server could also send a query to the Service Equipment for information it requires to evaluate a policy.
また、AAA Serverはそれが方針を評価するのを必要とする情報のために質問をService Equipmentに送ることができました。
4.4. Distributed Policy
4.4. 分配された方針
A policy is retrieved by a Policy Retrieval Point (PRP) from a Policy Repository, evaluated at a Policy Decision Point (PDP) or Policy Consumer, and enforced at a Policy Enforcement Point (PEP) or Policy Target [5].
方針は、Policy Decision Point(PDP)かPolicy Consumerで評価されたPolicy RepositoryからのPolicy Retrieval Point(PRP)によって検索されて、Policy Enforcement Point(PEP)かPolicy Target[5]で励行されます。
Generally, any of the AAA Servers involved in an authorization transaction may retrieve a policy or evaluate a policy, and any of the Service Equipment may enforce a policy. Policy Repositories may reside on any of the AAA Servers or be located elsewhere in the network.
一般に、承認トランザクションにかかわるAAA Serversのどれかは、方針を検索するか、または方針を評価するかもしれません、そして、Service Equipmentのいずれも政策を実行するかもしれません。 方針RepositoriesはAAA Serversのどれかに住んでいるか、またはネットワークにおけるほかの場所に位置するかもしれません。
Information against which policy conditions are evaluated (such as resource status, session state, or time of day) are accessible at Policy Information Points (PIPs) and might be accessed using Policy Information Blocks (PIBs). An interesting question in any authorization application that uses policy is where are the PDPs, PRPs, PIPs and PEPs?
Policy情報Blocks(PIBs)を使用することで、保険約款が評価される情報(リソース状態、セッション状態、または時刻などの)は、Policy情報Points(PIPs)でアクセスしやすく、アクセスされるかもしれません。 用途方針がどこであるかという何か承認アプリケーションにおける面白い質問は、PDPsと、PRPsと、PIPsとPEPsですか?
Figure 12 shows which policy elements may be available at different points in the model. In distributed services, there may be multiple Service Providers involved in the authorization transaction, and each may act as the policy elements shown below.
どの方針要素の図12ショーはモデルで異なったポイントで利用可能であるかもしれないか。 分配されたサービスには、承認トランザクションにかかわる複数のService Providersがあるかもしれません、そして、それぞれが以下で見せられた方針要素として機能するかもしれません。
Note that the User (or requester) may also be a PRP (e.g. use policy description to specify what service is being requested), a PIP (have information needed by other entities to evaluate their policy), and a PDP (decide if it will accept a service with specific parameters).
また、User(または、リクエスタ)がPRP(例えば、どんなサービスが要求されているかを指定するのに方針記述を使用する)と、PIP(それらの方針を評価するために他の実体によって必要とされた情報を持っている)と、PDPであるかもしれないことに注意してください(それが特定のパラメタでサービスを受け入れるかどうか決めてください)。
Vollbrecht, et al. Informational [Page 18] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [18ページ]情報のRFC2904AAA承認フレームワーク2000年8月
+------+ +------------------------------+
| | | User Home Organization |
| | | +-------------------+ PRP |
| | | | AAA Server | PIP |
| | | | | PDP |
| | | +-------------------+ |
| | | |
| | +------------------------------+
| |
| |
| | +------------------------------+
| User | | Service Provider |
| | | +-------------------+ PRP |
| PRP | | | AAA Server | PIP |
| PIP | | | | PDP |
| PDP | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | PIP |
| | | | Equipment | PEP |
| | | +-------------------+ |
| | | |
+------+ +------------------------------+
+------+ +------------------------------+ | | | ユーザホーム組織| | | | +-------------------+ PRP| | | | | AAAサーバ| 種| | | | | | PDP| | | | +-------------------+ | | | | | | | +------------------------------+ | | | | | | +------------------------------+ | ユーザ| | サービスプロバイダー| | | | +-------------------+ PRP| | PRP| | | AAAサーバ| 種| | 種| | | | PDP| | PDP| | +-------------------+ | | | | | | | | +-------------------+ | | | | | サービス| 種| | | | | 設備| 気力| | | | +-------------------+ | | | | | +------+ +------------------------------+
PRP = Policy Retrieval Point
PIP = Policy Information Point
PDP = Policy Decision Point
PEP = Policy Enforcement Point
方針検索ポイント種=方針情報ポイントPRP=PDPは政策決定ポイント気力=方針実施ポイントと等しいです。
Fig. 12 -- Where Different Policy Elements May be Located
図12 --どこDifferent Policy Elements、5月、Locatedになってくださいか。
An AAA protocol must be able to transport both policy definitions and the information needed to evaluate policies. It must also support queries for policy information.
AAAプロトコルは両方の方針定義を輸送できなければなりません、そして、情報は方針を評価する必要がありました。 また、それは方針情報のための質問をサポートしなければなりません。
5. Use of Attribute Certificates to Store Authorization Data
5. 承認データを保存する属性証明書の使用
This section outlines another mechanism that could be used for securely transporting the attributes on which an authorization decision is to be made. Work on X.509 Attribute Certificates is currently being undertaken in the Public Key Infrastructure (PKIX) Working Group [8]. This proposal is largely based on that work.
このセクションはしっかりと、作られている承認決定がことである属性を輸送するのに使用できた別のメカニズムについて概説します。 X.509 Attribute Certificatesへの作業は現在、公開鍵暗号基盤(PKIX)作業部会[8]で引き受けられています。 この提案はその仕事に主に基づいています。
When considering authorization using certificate-based mechanisms, one is often less interested in the identity of the entity than in some other attributes, (e.g. roles, account limits etc.), which should be used to make an authorization decision.
証明書ベースのメカニズムを使用することで承認を考える場合、1つがある他の属性ほどしばしば実体のアイデンティティに興味を持っていないとき、承認決定をするのに使用されるべきである(例えば、アカウントの限界役割など。)です。
Vollbrecht, et al. Informational [Page 19] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [19ページ]情報のRFC2904AAA承認フレームワーク2000年8月
In many such cases, it is better to separate this information from the identity for management, security, interoperability or other reasons. However, this authorization information may also need to be protected in a fashion similar to a public key certificate. The name used here for such a structure is an Attribute Certificate (AC) which is a digitally signed (certified) set of attributes.
そのような多くの場合では、管理、セキュリティ、相互運用性または他の理由でアイデンティティとこの情報を切り離すほうがよいです。 しかしながら、また、この承認情報は、公開鍵証明書と同様のファッションで保護される必要があるかもしれません。 そのような構造にここで使用された名前はデジタルに署名している(公認された)セットの属性であるAttribute Certificate(西暦)です。
An AC is a structure that is similar to an X.509 public key certificate [9] with the main difference being that it contains no public key. The AC typically contains group membership, role, clearance and other access control information associated with the AC owner. A syntax for ACs is also defined in the X.509 standard.
西暦はX.509公開鍵証明書[9]と公開鍵を全く含んでいないということである主な違いで同様の構造です。 西暦はグループ会員資格、役割、クリアランス、および交流所有者に関連している他のアクセス制御情報を通常含んでいます。 また、ACsのための構文はX.509規格で定義されます。
When making an access decision based on an AC, an access decision function (in a PEP, PDP or elsewhere) may need to ensure that the appropriate AC owner is the entity that has requested access. The linkage between the request and the AC can be achieved if the AC has a "pointer" to a Public Key Certificate (PKC) for the requester and that the PKC has been used to authenticate the request. Other forms of linkage can be defined which work with other authentication schemes.
西暦に基づくアクセス決定をするとき、アクセス決定関数(PEP、PDPかほかの場所)は、適切な交流所有者がアクセサリーを要求した実体であることを保証する必要があるかもしれません。 西暦がリクエスタのためのPublic Key Certificate(PKC)に「指針」を持っているなら、要求と西暦の間のリンケージを達成できます、そして、PKCは、要求を認証するのに使用されました。 他のフォームのリンケージを定義できます(他の認証体系で働いています)。
As there is often confusion about the difference between public key certificates (PKC's) and attribute certificates (ACs), an analogy may help. A PKC can be considered to be like a passport: it identifies the owner, it tends to be valid for a long period, it is difficult to forge, and it has a strong authentication process to establish the owner's identity. An AC is more like an entry visa in that it is typically issued by a different authority than the passport issuing authority, and it doesn't have as long a validity period as a passport. Acquiring an entry visa typically requires presenting a passport that authenticates that owner's identity. As a consequence, acquiring the entry visa becomes a simpler procedure. The entry visa will refer to the passport as a part of how that visa specifies the terms under which the passport owner is authorized to enter a country.
公開鍵証明書(PKCのもの)と属性証明書(ACs)の違いに関して混乱がしばしばあって、類推は助けるかもしれません。 PKCがパスポートに似ていると考えることができます: 所有者を特定します、そして、長い間有効である傾向があります、そして、鍛造するのが難しく、強い認証は、所有者のアイデンティティを証明するためにそれによって処理されます。 それがパスポート発行機関と異なった権威によって通常発行されるので、西暦はさらに入国査証に似ています、そして、それはパスポートと同じくらい長い有効期間を過しません。 入国査証を取得するのは、その所有者のアイデンティティを認証するパスポートを提示するのを通常必要とします。 結果として、入国査証を取得するのは、より簡単な手順になります。 入国査証はそのビザがどう、入国するのにパスポート所有者に権限を与える諸条件を指定するかに関する部分としてのパスポートを示すでしょう。
In conjunction with authentication services, ACs provide a means to transport authorization information securely to applications. However, there are a number of possible communication paths that an AC may take.
認証サービスに関連して、ACsはしっかりと承認情報をアプリケーションに輸送する手段を提供します。 しかしながら、西暦が取るかもしれない多くの可能な通信路があります。
In some environments, it is suitable for a client to "push" an AC to a server. This means that no new connections between the client and server domains are required. It also means that no search burden is imposed on servers, which improves performance.
いくつかの環境で、クライアントがサーバに西暦を「押す」であることは、適当です。これは、クライアントとサーバドメインとのどんな新しい関係も必要でないことを意味します。 また、それは、検索負担が全くサーバに課されないことを意味します(性能を向上させます)。
Vollbrecht, et al. Informational [Page 20] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [20ページ]情報のRFC2904AAA承認フレームワーク2000年8月
In other cases, it is more suitable for a client simply to authenticate to the server and for the server to request the client's AC from an AC issuer or a repository. A major benefit of the this model is that it can be implemented without changes to the client and client/server protocol. It is also more suitable for some inter- domain cases where the client's rights should be assigned within the server's domain, rather than within the client's "home" domain.
他の場合では、交流発行人か倉庫からクライアントの西暦を要求するのは単にサーバに認証するクライアントとサーバにより適しています。 主要な利益、このモデルはクライアントとクライアント/サーバプロトコルへの変化なしでそれを実装することができるということです。 また、それもクライアントの権利がクライアントの「ホーム」ドメインの中でというよりむしろサーバのドメインの中で割り当てられるべきであるいくつかの相互ドメインケースにより適しています。
There are a number of possible exchanges that can occur, and there are three entities involved: client, server, and AC issuer. In addition the use of a directory service as a repository for AC retrieval may be supported.
起こることができる多くの可能な交換があります、そして、かかわった3つの実体があります: クライアント、サーバ、および交流発行人。 さらに、倉庫としてのディレクトリサービスの交流検索の使用はサポートされるかもしれません。
Figure 13 shows an abstract view of the exchanges that may involve ACs. Note that the lines in the diagram represent protocols which must be defined, not data flows. The PKIX working group will define the required acquisition protocols. One candidate for the lookup protocols is LDAP (once an LDAP schema exists which states where an AC is to be found).
図13はACsにかかわるかもしれない交換の抽象的な視点を示しています。 ダイヤグラムによる系列がデータフローではなく、定義しなければならないプロトコルを表すことに注意してください。 PKIXワーキンググループは必要な獲得プロトコルを定義するでしょう。 ルックアッププロトコルの1人の候補がLDAP(かつての西暦がどこで見つけられることになっているかを述べるLDAP図式は存在している)です。
+--------------+ +---------------+
| AAA Server/ | | |
| AC Issuer +----+ | Directory |
| | | | |
+--+-----------+ | Server +-------+-------+
| | Acquisition |
|Client | |Server
|Acquisition +----------------------+ |Lookup
| | |
+--+-----------+ +--+----+-------+
| | AC in application | Service |
| User +------------------------+ Equipment/ |
| | protocol | AAA Server |
+--+-----------+ +---------------+
|
| Client Lookup
+--+-----------+
| |
| Directory |
| |
+--------------+
+--------------+ +---------------+ | AAAサーバ/| | | | 交流発行人+----+ | ディレクトリ| | | | | | +--+-----------+ | サーバ+-------+-------+ | | 獲得| |クライアント| |サーバ|獲得+----------------------+ |ルックアップ| | | +--+-----------+ +--+----+-------+ | | アプリケーションにおける西暦| サービス| | ユーザ+------------------------+ 設備/| | | プロトコル| AAAサーバ| +--+-----------+ +---------------+ | | クライアントルックアップ+--+-----------+ | | | ディレクトリ| | | +--------------+
Fig. 13 -- AC Exchanges
図13--交流交換
Vollbrecht, et al. Informational [Page 21] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [21ページ]情報のRFC2904AAA承認フレームワーク2000年8月
Figure 14 shows the data flows which may occur in one particular case, that termed "push" above (section 2.1.3).
図14はある特定の場合で現れるかもしれないデータフロー、(セクション2.1.3)より上で「プッシュ」と呼ばれたそれを示しています。
+--------------+
| AAA Server/ |
| AC Issuer |
| |
+--+-----------+
|
|Client
|Acquisition (1)
|
+--+-----------+ +---------------+
| | AC in application | Service |
| User +------------------------+ Equipment/ |
| | protocol (2) | AAA Server |
+--------------+ +---------------+
+--------------+ | AAAサーバ/| | 交流発行人| | | +--+-----------+ | |クライアント|獲得(1)| +--+-----------+ +---------------+ | | アプリケーションにおける西暦| サービス| | ユーザ+------------------------+ 設備/| | | プロトコル(2)| AAAサーバ| +--------------+ +---------------+
Fig. 14 -- One example of an AC exchange
図14--交流交換に関する1つの例
In the diagram, the user first contacts the AC Issuer and then incorporates the AC into the application protocol. The Service Equipment must then validate the AC and use it as the basis for the access decision (this functionality may be distributed between a PEP and PDP).
In the diagram, the user first contacts the AC Issuer and then incorporates the AC into the application protocol. The Service Equipment must then validate the AC and use it as the basis for the access decision (this functionality may be distributed between a PEP and PDP).
6. Resource Management
6. Resource Management
Authorization requests may be chained through a set of servers, as described in previous sections. Each of the servers may have a contractual relationship with servers on either side of it in the chain. In many of the applications being considered, the authorization results in establishing of an ongoing service which we call a session. Each of the servers involved in the authorization may also want to keep track of the state of the session, and be able to effect changes to the session if required. To make it simple to discuss this capability, we assume that each AAA Server MAY have a Resource Manager component. Resource Managers tracking the same session need to be able to initiate changes to the session, and to inform other Resource Managers when changes occur. Communication between Resource Managers creates requirements for an authorization protocol.
Authorization requests may be chained through a set of servers, as described in previous sections. Each of the servers may have a contractual relationship with servers on either side of it in the chain. In many of the applications being considered, the authorization results in establishing of an ongoing service which we call a session. Each of the servers involved in the authorization may also want to keep track of the state of the session, and be able to effect changes to the session if required. To make it simple to discuss this capability, we assume that each AAA Server MAY have a Resource Manager component. Resource Managers tracking the same session need to be able to initiate changes to the session, and to inform other Resource Managers when changes occur. Communication between Resource Managers creates requirements for an authorization protocol.
An example of the use of resource management might be a user which sets up a QoS path through two ISPs, and while this path is active, one of the ISPs gets a request for more bandwidth from a higher priority user. The ISP may need to take some bandwidth from a the lower priority user's previously allocated session and give it to the
An example of the use of resource management might be a user which sets up a QoS path through two ISPs, and while this path is active, one of the ISPs gets a request for more bandwidth from a higher priority user. The ISP may need to take some bandwidth from a the lower priority user's previously allocated session and give it to the
Vollbrecht, et al. Informational [Page 22] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht, et al. Informational [Page 22] RFC 2904 AAA Authorization Framework August 2000
new request. To do this, each of the administrations in the authorization path must be informed and agree to the change (this could be considered to be "authorizing the new value").
new request. To do this, each of the administrations in the authorization path must be informed and agree to the change (this could be considered to be "authorizing the new value").
6.1. Session Management and State Synchronization
6.1. Session Management and State Synchronization
When an AAA Server grants authorization of some resource to an AAA requester (either a User or another AAA Server), the server may need to maintain session state information. This is used to make decisions about new sessions based on the state of current sessions, and to allow monitoring of sessions by all interested AAA Servers.
When an AAA Server grants authorization of some resource to an AAA requester (either a User or another AAA Server), the server may need to maintain session state information. This is used to make decisions about new sessions based on the state of current sessions, and to allow monitoring of sessions by all interested AAA Servers.
Each session is identified by a session identifier, which must be unique within each AAA Server. Communication between AAA Servers must include the session identifier. It is desirable that the session identifier is the same across all AAA servers, otherwise each server will have to map identifiers from other servers to its own identifiers. A single session identifier significantly simplifies auditing and session control functions.
Each session is identified by a session identifier, which must be unique within each AAA Server. Communication between AAA Servers must include the session identifier. It is desirable that the session identifier is the same across all AAA servers, otherwise each server will have to map identifiers from other servers to its own identifiers. A single session identifier significantly simplifies auditing and session control functions.
Maintaining session state across AAA administrative boundaries increases the complexity of the problem, especially if each AAA Server in the trust chain must keep state as well. This can be viewed as an interdomain database replication problem. The protocol must include tools to help manage replicated state. Some of the problems to be addressed are:
Maintaining session state across AAA administrative boundaries increases the complexity of the problem, especially if each AAA Server in the trust chain must keep state as well. This can be viewed as an interdomain database replication problem. The protocol must include tools to help manage replicated state. Some of the problems to be addressed are:
a) Service Equipment must be able to notify its Resource Manager when
a session terminates or changes state in some other way. The
Resource Manager must inform other Resource Managers which keep
state for this session.
a) Service Equipment must be able to notify its Resource Manager when a session terminates or changes state in some other way. The Resource Manager must inform other Resource Managers which keep state for this session.
b) The Resource Manager will need to set a time limit for each
session which must be refreshed by having the Resource Manager
query for authoritative status or by having the authoritative
source send periodic keep alive messages that are forwarded to all
Resource Managers in the authorization chain. Determining the
appropriate session lifetime may be application specific and
depends on the acceptable level of risk. If the service being
offered is billed based on time, the session lifetime may need to
be relatively small; if the service is billed on usage, the
lifetime may be relatively large.
b) The Resource Manager will need to set a time limit for each session which must be refreshed by having the Resource Manager query for authoritative status or by having the authoritative source send periodic keep alive messages that are forwarded to all Resource Managers in the authorization chain. Determining the appropriate session lifetime may be application specific and depends on the acceptable level of risk. If the service being offered is billed based on time, the session lifetime may need to be relatively small; if the service is billed on usage, the lifetime may be relatively large.
c) Any Resource Manager in the chain must have the ability to
terminate a session. This requires the Resource Manager to have
knowledge of at least the adjacent AAA Servers in the
authorization chain.
c) Any Resource Manager in the chain must have the ability to terminate a session. This requires the Resource Manager to have knowledge of at least the adjacent AAA Servers in the authorization chain.
Vollbrecht, et al. Informational [Page 23] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht, et al. Informational [Page 23] RFC 2904 AAA Authorization Framework August 2000
An example of how resource management can be used is in the PPP dialin application. A home ISP may wish to restrict the number of concurrent sessions that a user can have at any given time. This is particularly important when service providers give all-you-can-eat Internet access. The possibility for fraud is quite large, since a user could provide his or her username/password to many people, causing a loss of revenue. Resource management would allow the home ISP AAA server to identify when a user is active and to reject any authorization request for the user until termination indication is received from the NAS or until the session expires.
An example of how resource management can be used is in the PPP dialin application. A home ISP may wish to restrict the number of concurrent sessions that a user can have at any given time. This is particularly important when service providers give all-you-can-eat Internet access. The possibility for fraud is quite large, since a user could provide his or her username/password to many people, causing a loss of revenue. Resource management would allow the home ISP AAA server to identify when a user is active and to reject any authorization request for the user until termination indication is received from the NAS or until the session expires.
6.2. The Resource Manager
6.2. The Resource Manager
This section describes the functions of the Resource Manager in more detail.
This section describes the functions of the Resource Manager in more detail.
The Resource Manager is the component which tracks the state of sessions associated with an AAA Server or Service Equipment. It also may allocate resources to a session (e.g. IP addresses) and may track use of resources allocated by peer resource managers to a session (e.g. bandwidth in a foreign administrative domain). The resource manager also provides interfaces to allow the User to acquire or release authorized sessions.
The Resource Manager is the component which tracks the state of sessions associated with an AAA Server or Service Equipment. It also may allocate resources to a session (e.g. IP addresses) and may track use of resources allocated by peer resource managers to a session (e.g. bandwidth in a foreign administrative domain). The resource manager also provides interfaces to allow the User to acquire or release authorized sessions.
The Resource Manager maintains all session specific AAA state information required by the AAA Server. That state information may include pointers to peer Resource Managers in other administrative domains that possess additional AAA state information that refers to the same session. The Resource Manager is the anchor point in the AAA Server from which a session can be controlled, monitored, and coordinated even if that session is consuming network resources or services across multiple Service Provider administrative domains.
The Resource Manager maintains all session specific AAA state information required by the AAA Server. That state information may include pointers to peer Resource Managers in other administrative domains that possess additional AAA state information that refers to the same session. The Resource Manager is the anchor point in the AAA Server from which a session can be controlled, monitored, and coordinated even if that session is consuming network resources or services across multiple Service Provider administrative domains.
The Resource Manager has several important functions:
The Resource Manager has several important functions:
a) It allows a Service Provider operations staff to inspect the
status of any of the allocated resources and services including
resources that span foreign Service Provider administrative
boundaries. The peer Resource Managers will cooperatively share
only the state information subset that is required to assist in
diagnosing cross-domain trouble tickets. The network operator may
also modify or altogether cancel one of the User's active
authorizations.
a) It allows a Service Provider operations staff to inspect the status of any of the allocated resources and services including resources that span foreign Service Provider administrative boundaries. The peer Resource Managers will cooperatively share only the state information subset that is required to assist in diagnosing cross-domain trouble tickets. The network operator may also modify or altogether cancel one of the User's active authorizations.
b) It is the process contacted by other Resource Managers to inform
the AAA Server that a specific session has been cancelled. This
information is relayed to the other peer Resource Managers that
also know about that session and hence must cancel it.
b) It is the process contacted by other Resource Managers to inform the AAA Server that a specific session has been cancelled. This information is relayed to the other peer Resource Managers that also know about that session and hence must cancel it.
Vollbrecht, et al. Informational [Page 24] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht, et al. Informational [Page 24] RFC 2904 AAA Authorization Framework August 2000
c) The Resource Manager conceals the identity and location of its
private internal AAA components from other administrative domains
and from the User, while at the same time facilitating cooperation
between those domains.
c) The Resource Manager conceals the identity and location of its private internal AAA components from other administrative domains and from the User, while at the same time facilitating cooperation between those domains.
d) The Resource Manager cooperates with "policy servers" or Policy
Decision Points (PDPs). The Resource Manager maintains internal
state information, possibly complex cross-administrative domain
information, supported by dialogues with its peer Resource
Managers. A policy server can use the state information when
evaluating a particular policy.
d) The Resource Manager cooperates with "policy servers" or Policy Decision Points (PDPs). The Resource Manager maintains internal state information, possibly complex cross-administrative domain information, supported by dialogues with its peer Resource Managers. A policy server can use the state information when evaluating a particular policy.
e) The separation of the Resource Manager and the policy server into
two distinct architectural components allows a single session to
span multiple administrative domains, where each administrative
domain has one or more policy server cooperating with its Resource
Manager.
e) The separation of the Resource Manager and the policy server into two distinct architectural components allows a single session to span multiple administrative domains, where each administrative domain has one or more policy server cooperating with its Resource Manager.
AAA resource managers will normally use the same trust relationships needed for authorization sequences. It is possible for independent relationships to be established, but that is discouraged.
AAA resource managers will normally use the same trust relationships needed for authorization sequences. It is possible for independent relationships to be established, but that is discouraged.
7. AAA Message Forwarding and Delivery
7. AAA Message Forwarding and Delivery
An AAA Server is responsible for securely forwarding AAA messages to the correct destination system or process in the AAA infrastructure. Two well known examples are forwarding AAA messages for a roaming AAA service, and forwarding AAA messages for a distributed AAA service. The same principle can also be applied to intra-domain communications. The message forwarding is done in one of two modes.
An AAA Server is responsible for securely forwarding AAA messages to the correct destination system or process in the AAA infrastructure. Two well known examples are forwarding AAA messages for a roaming AAA service, and forwarding AAA messages for a distributed AAA service. The same principle can also be applied to intra-domain communications. The message forwarding is done in one of two modes.
The first mode is when an AAA server needs to forward a message to a peer AAA server that has a known "logical destination address" that must be resolved by an application-specific procedure into its actual network address. Typically the forwarding procedure indexes into a database by an application-specific identifier to discover the peer's network address. For example, in the roaming dialin application, the application-specific identifier may be an NAI. A bandwidth brokerage application would use other search indices unique to its problem domain to select the addressed peer AAA server. After the address resolution procedure has completed successfully, then the AAA server transmits the message to its peer over the connection associated with that destination network address.
The first mode is when an AAA server needs to forward a message to a peer AAA server that has a known "logical destination address" that must be resolved by an application-specific procedure into its actual network address. Typically the forwarding procedure indexes into a database by an application-specific identifier to discover the peer's network address. For example, in the roaming dialin application, the application-specific identifier may be an NAI. A bandwidth brokerage application would use other search indices unique to its problem domain to select the addressed peer AAA server. After the address resolution procedure has completed successfully, then the AAA server transmits the message to its peer over the connection associated with that destination network address.
The second mode is when the AAA server already has an established session representing an authorization. The session's state contains the addressing and context used to direct the message to its destination peer AAA server, PDP, PEP, or User. The message is sent
The second mode is when the AAA server already has an established session representing an authorization. The session's state contains the addressing and context used to direct the message to its destination peer AAA server, PDP, PEP, or User. The message is sent
Vollbrecht, et al. Informational [Page 25] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht, et al. Informational [Page 25] RFC 2904 AAA Authorization Framework August 2000
over the AAA server's connection to that destination peer, multiplexed with other session's messages. The message must be qualified by a session identifier that is understood by both end points. The AAA message's destination may be either intra- administrative domain, or inter-administrative domain. In the former case, the destination process may reside on the same system as the AAA server.
over the AAA server's connection to that destination peer, multiplexed with other session's messages. The message must be qualified by a session identifier that is understood by both end points. The AAA message's destination may be either intra- administrative domain, or inter-administrative domain. In the former case, the destination process may reside on the same system as the AAA server.
In addition to the above message forwarding processing, the underlying message delivery service must meet the following requirements:
In addition to the above message forwarding processing, the underlying message delivery service must meet the following requirements:
- Unicast capability -- An end system can send a message to any
other end system with minimal latency of session setup/disconnect
overhead messages, and no end system overhead of keeping state
information about every potential peer.
- Unicast capability -- An end system can send a message to any other end system with minimal latency of session setup/disconnect overhead messages, and no end system overhead of keeping state information about every potential peer.
- Data integrity and error detection -- This data transport protocol
assumes an underlying datagram network layer service that includes
packet discard on error detection, and data integrity protection
against third party modifications.
- Data integrity and error detection -- This data transport protocol assumes an underlying datagram network layer service that includes packet discard on error detection, and data integrity protection against third party modifications.
- Reliable data transport assurance -- When an end system
successfully receives a message marked receipt requested, it must
acknowledge that message to the sending system by either
piggybacking the acknowledgement on an application-specific reply
message, or else as a standalone acknowledgement message. The
sending system maintains a retry timer; when the timer expires,
the sending system retransmits a copy of its original message. It
gives up after a configurable number of unsuccessful retries.
- Reliable data transport assurance -- When an end system successfully receives a message marked receipt requested, it must acknowledge that message to the sending system by either piggybacking the acknowledgement on an application-specific reply message, or else as a standalone acknowledgement message. The sending system maintains a retry timer; when the timer expires, the sending system retransmits a copy of its original message. It gives up after a configurable number of unsuccessful retries.
- Sequenced data delivery -- If multiple messages are sent between a
pair of end systems, those messages are delivered to the addressed
application in the same order as they were transmitted.
Duplicates are silently suppressed.
- Sequenced data delivery -- If multiple messages are sent between a pair of end systems, those messages are delivered to the addressed application in the same order as they were transmitted. Duplicates are silently suppressed.
- Responsive to network congestion feedback -- When the network
enters into congestion, the end systems must detect that
condition, and they must back off their transmission rate until
the congestion subsides. The back off and recovery algorithms
must avoid oscillations.
- Responsive to network congestion feedback -- When the network enters into congestion, the end systems must detect that condition, and they must back off their transmission rate until the congestion subsides. The back off and recovery algorithms must avoid oscillations.
8. End-to-End Security
8. End-to-End Security
When AAA servers communicate through intermediate AAA servers, such as brokers, it may be necessary that a part of the payload be secure between the originator and the target AAA server. The security requirement may consist of one or more of the following: end-to-end
When AAA servers communicate through intermediate AAA servers, such as brokers, it may be necessary that a part of the payload be secure between the originator and the target AAA server. The security requirement may consist of one or more of the following: end-to-end
Vollbrecht, et al. Informational [Page 26] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht, et al. Informational [Page 26] RFC 2904 AAA Authorization Framework August 2000
message integrity, confidentiality, replay protection, and nonrepudiation. Furthermore, it is a requirement that intermediate AAA servers be able to append information such as local policy to a message before forwarding the message to its intended destination. It may also be required that an intermediate AAA Server sign such appended information.
message integrity, confidentiality, replay protection, and nonrepudiation. Furthermore, it is a requirement that intermediate AAA servers be able to append information such as local policy to a message before forwarding the message to its intended destination. It may also be required that an intermediate AAA Server sign such appended information.
This requirement has been clearly documented in [10], which describes many current weaknesses of the RADIUS protocol [11] in roaming networks since RADIUS does not provide such functionality. One well-known attack is the ability for the intermediate nodes to modify critical accounting information, such as a session time.
This requirement has been clearly documented in [10], which describes many current weaknesses of the RADIUS protocol [11] in roaming networks since RADIUS does not provide such functionality. One well-known attack is the ability for the intermediate nodes to modify critical accounting information, such as a session time.
Most popular security protocols (e.g. IPSec, SSL, etc.) do not provide the ability to secure a portion of the payload. Therefore, it may be necessary for the AAA protocol to implement its own security extensions to provide end-to-end security.
Most popular security protocols (e.g. IPSec, SSL, etc.) do not provide the ability to secure a portion of the payload. Therefore, it may be necessary for the AAA protocol to implement its own security extensions to provide end-to-end security.
9. Streamlined Authorization Process
9. Streamlined Authorization Process
The techniques described above allow for great flexibility in distributing the components required for authentication and authorization. However, working groups such as Roamops and MobileIP have identified requirements to minimize Internet traversals in order to reduce latency. To support these requirements, data fields necessary for both authentication and authorization SHOULD be able to be carried in a single message set. This is especially important when there are intermediate servers (such as Brokers) in the AAA chain.
The techniques described above allow for great flexibility in distributing the components required for authentication and authorization. However, working groups such as Roamops and MobileIP have identified requirements to minimize Internet traversals in order to reduce latency. To support these requirements, data fields necessary for both authentication and authorization SHOULD be able to be carried in a single message set. This is especially important when there are intermediate servers (such as Brokers) in the AAA chain.
Furthermore, it should be possible for the Brokers to allow end-to- end (direct) authentication and authorization. This can be done as follows. The User Home Organization generates a ticket which is signed using the UHO's private key. The ticket is carried in the accounting messages. The accounting messages must flow through the Broker since the Broker is acting as the settlement agent and requires this information. There are Brokers that will require to be in the authentication and authorization path as well since they will use this information to detect fraudulent activity, so the above should be optional.
Furthermore, it should be possible for the Brokers to allow end-to- end (direct) authentication and authorization. This can be done as follows. The User Home Organization generates a ticket which is signed using the UHO's private key. The ticket is carried in the accounting messages. The accounting messages must flow through the Broker since the Broker is acting as the settlement agent and requires this information. There are Brokers that will require to be in the authentication and authorization path as well since they will use this information to detect fraudulent activity, so the above should be optional.
In order for end-to-end authentication and authorization to occur, it may be necessary for the Broker to act as a certificate authority. All members of the roaming consortium would be able to trust each other (to an extent) using the certificates. A Service Provider's AAA server that sends a request to the Broker should be able to receive a redirect message which would allow the two peers (Service Provider and UHO) to interact directly. The redirect message from
In order for end-to-end authentication and authorization to occur, it may be necessary for the Broker to act as a certificate authority. All members of the roaming consortium would be able to trust each other (to an extent) using the certificates. A Service Provider's AAA server that sends a request to the Broker should be able to receive a redirect message which would allow the two peers (Service Provider and UHO) to interact directly. The redirect message from
Vollbrecht, et al. Informational [Page 27] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht, et al. Informational [Page 27] RFC 2904 AAA Authorization Framework August 2000
the Broker should include the UHO's certificate, which eliminates the Service Provider from accessing the certificate archive. The request from the Service Provider could include its own certificate, and a token from the Broker's redirect message that is timestamped and guarantees that the Service Provider is in good standing with the Broker. This eliminates the home domain from accessing the Certificate Revocation List (CRL).
the Broker should include the UHO's certificate, which eliminates the Service Provider from accessing the certificate archive. The request from the Service Provider could include its own certificate, and a token from the Broker's redirect message that is timestamped and guarantees that the Service Provider is in good standing with the Broker. This eliminates the home domain from accessing the Certificate Revocation List (CRL).
10. Summary of the Authorization Framework
10. Summary of the Authorization Framework
The above has introduced the basic players in an authorization transaction as User, User Home Organization, Service Provider's AAA Server, and Service Equipment. It has discussed relationships between entities based on agreements or contracts, and on "trust". Examples of authorization sequences have been given.
The above has introduced the basic players in an authorization transaction as User, User Home Organization, Service Provider's AAA Server, and Service Equipment. It has discussed relationships between entities based on agreements or contracts, and on "trust". Examples of authorization sequences have been given.
Concepts of roaming and distributed services have been briefly described. Combination of roaming and distributed services was also considered and the concept of a "wholesaler" or Broker was introduced. We have considered the use of policies and attribute certificates to store and transmit authorization data. We discussed the problem of managing the resources to which access has been authorized including the problem of tracking state information for session-oriented services, and we defined the Resource Manager component of a AAA Server. We considered the problem of forwarding AAA messages among servers in possibly different administrative domains. We considered the need for end-to-end security of portions of the payload of authorization messages that pass through intermediate AAA Servers. Finally we stressed the need for support of a streamlined authorization process that minimizes delay for latency-sensitive applications.
Concepts of roaming and distributed services have been briefly described. Combination of roaming and distributed services was also considered and the concept of a "wholesaler" or Broker was introduced. We have considered the use of policies and attribute certificates to store and transmit authorization data. We discussed the problem of managing the resources to which access has been authorized including the problem of tracking state information for session-oriented services, and we defined the Resource Manager component of a AAA Server. We considered the problem of forwarding AAA messages among servers in possibly different administrative domains. We considered the need for end-to-end security of portions of the payload of authorization messages that pass through intermediate AAA Servers. Finally we stressed the need for support of a streamlined authorization process that minimizes delay for latency-sensitive applications.
The intent is that this will provide support for discussing and understanding requirements of specific applications that need authorization services.
The intent is that this will provide support for discussing and understanding requirements of specific applications that need authorization services.
11. Security Considerations
11. Security Considerations
Authorization is itself a security mechanism. As such, it is important that authorization protocols cannot easily be abused to circumvent the protection they are intended to ensure. It is the responsibility of protocol designers to design their protocols to be resilient against well-known types of attacks. The following are some considerations that may guide protocol designers in the development of authorization protocols.
Authorization is itself a security mechanism. As such, it is important that authorization protocols cannot easily be abused to circumvent the protection they are intended to ensure. It is the responsibility of protocol designers to design their protocols to be resilient against well-known types of attacks. The following are some considerations that may guide protocol designers in the development of authorization protocols.
Vollbrecht, et al. Informational [Page 28] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht, et al. Informational [Page 28] RFC 2904 AAA Authorization Framework August 2000
Authorization protocols must not be susceptible to replay attacks. If authentication data is carried with the authorization data, for example, the authentication protocol used must either be impervious to replay or else the confidentiality of the authentication data must be protected.
Authorization protocols must not be susceptible to replay attacks. If authentication data is carried with the authorization data, for example, the authentication protocol used must either be impervious to replay or else the confidentiality of the authentication data must be protected.
If proxying is required, the authorization protocol must not be susceptible to man-in-the-middle attacks.
If proxying is required, the authorization protocol must not be susceptible to man-in-the-middle attacks.
If the push model is used, the confidentiality of the authorization data must be ensured so that it may not be hijacked by third parties and used to obtain a service fraudulently.
If the push model is used, the confidentiality of the authorization data must be ensured so that it may not be hijacked by third parties and used to obtain a service fraudulently.
If the agent model is used, the binding between the authorization and the service itself must be protected to prevent service authorized to one party from being fraudulently received by another.
If the agent model is used, the binding between the authorization and the service itself must be protected to prevent service authorized to one party from being fraudulently received by another.
In addition to guarding against circumvention, authorization protocols designed according to this framework will have some intrinsic security requirements. These are included among the requirements in [2] and summarized briefly below.
In addition to guarding against circumvention, authorization protocols designed according to this framework will have some intrinsic security requirements. These are included among the requirements in [2] and summarized briefly below.
Among the intrinsic security needs is the fact that authorization protocols may carry sensitive information. It is necessary to protect such information from disclosure to unauthorized parties including (as discussed in section 8) even certain parties involved in the authorization decision.
Among the intrinsic security needs is the fact that authorization protocols may carry sensitive information. It is necessary to protect such information from disclosure to unauthorized parties including (as discussed in section 8) even certain parties involved in the authorization decision.
We have discussed the use of multi-party trust chains involving relaying of authorization data through brokers or other parties. In such cases, the integrity of the chain must be maintained. It may be necessary to protect the data exchanged between parties using such mechanisms as encryption and digital signatures.
We have discussed the use of multi-party trust chains involving relaying of authorization data through brokers or other parties. In such cases, the integrity of the chain must be maintained. It may be necessary to protect the data exchanged between parties using such mechanisms as encryption and digital signatures.
Finally, because authorization will be necessary to gain access to many Internet services, a denial of service attack against an authorization server can be just as effective as a denial of service attack against the service equipment itself in preventing access to Internet services.
Finally, because authorization will be necessary to gain access to many Internet services, a denial of service attack against an authorization server can be just as effective as a denial of service attack against the service equipment itself in preventing access to Internet services.
Glossary
Glossary
Attribute Certificate -- structure containing authorization
attributes which is digitally signed using public key
cryptography.
Attribute Certificate -- structure containing authorization attributes which is digitally signed using public key cryptography.
Vollbrecht, et al. Informational [Page 29] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht, et al. Informational [Page 29] RFC 2904 AAA Authorization Framework August 2000
Contract Relationship -- a relation established between two or more
business entities where terms and conditions determine the
exchange of goods or services.
Contract Relationship -- a relation established between two or more business entities where terms and conditions determine the exchange of goods or services.
Distributed Service -- a service that is provided by more than one
Service Provider acting in concert.
Distributed Service -- a service that is provided by more than one Service Provider acting in concert.
Dynamic Trust Relationship -- a secure relationship which is
dynamically created between two entities who may never have had
any prior relationship. This relationship can be created if the
involved entities have a mutually trusted third party. Example: A
merchant trusts a cardholder at the time of a payment transaction
because they both are known by a credit card organization.
Dynamic Trust Relationship -- a secure relationship which is dynamically created between two entities who may never have had any prior relationship. This relationship can be created if the involved entities have a mutually trusted third party. Example: A merchant trusts a cardholder at the time of a payment transaction because they both are known by a credit card organization.
Policy Decision Point (PDP) -- The point where policy decisions are
made.
Policy Decision Point (PDP) -- The point where policy decisions are made.
Policy Enforcement Point (PEP) -- The point where the policy
decisions are actually enforced.
Policy Enforcement Point (PEP) -- The point where the policy decisions are actually enforced.
Resource Manager -- the component of an AAA Server which tracks the
state of sessions associated with the AAA Server or its associated
Service Equipment and provides an anchor point from which a
session can be controlled, monitored, and coordinated.
Resource Manager -- the component of an AAA Server which tracks the state of sessions associated with the AAA Server or its associated Service Equipment and provides an anchor point from which a session can be controlled, monitored, and coordinated.
Roaming -- An authorization transaction in which the Service Provider
and the User Home Organization are two different organizations.
(Note that the dialin application is one for which roaming has
been actively considered, but this definition encompasses other
applications as well.)
Roaming -- An authorization transaction in which the Service Provider and the User Home Organization are two different organizations. (Note that the dialin application is one for which roaming has been actively considered, but this definition encompasses other applications as well.)
Security Association -- a collection of security contexts, between a
pair of nodes, which may be applied to protocol messages exchanged
between them. Each context indicates an authentication algorithm
and mode, a secret (a shared key, or appropriate public/private
key pair), and a style of replay protection in use. [12]
Security Association -- a collection of security contexts, between a pair of nodes, which may be applied to protocol messages exchanged between them. Each context indicates an authentication algorithm and mode, a secret (a shared key, or appropriate public/private key pair), and a style of replay protection in use. [12]
Service Equipment -- the equipment which provides a service.
Service Equipment -- the equipment which provides a service.
Service Provider -- an organization which provides a service.
Service Provider -- an organization which provides a service.
Static Trust Relationship -- a pre-established secure relationship
between two entities created by a trusted party. This
relationship facilitates the exchange of AAA messages with a
certain level of security and traceability. Example: A network
operator (trusted party) who has access to the wiring closet
Static Trust Relationship -- a pre-established secure relationship between two entities created by a trusted party. This relationship facilitates the exchange of AAA messages with a certain level of security and traceability. Example: A network operator (trusted party) who has access to the wiring closet
Vollbrecht, et al. Informational [Page 30] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht, et al. Informational [Page 30] RFC 2904 AAA Authorization Framework August 2000
creates a connection between a user's wall outlet and a particular
network port. The user is thereafter trusted -- to a certain
level -- to be connected to this particular network port.
creates a connection between a user's wall outlet and a particular network port. The user is thereafter trusted -- to a certain level -- to be connected to this particular network port.
User -- the entity seeking authorization to use a resource or 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.
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.
References
References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[2] 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.
[2] 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.
[3] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross,
G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA
Authorization Application Examples", RFC 2905, August 2000.
[3] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Application Examples", RFC 2905, August 2000.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Stevens, M., "Policy Framework", Work in Progress.
[5] Stevens, M., "Policy Framework", Work in Progress.
[6] Strassner, John, Ed Ellesson, and Bob Moore, "Policy Core
Information Model -- Version 1 Specification", Work in Progress.
[6] Strassner, John, Ed Ellesson, and Bob Moore, "Policy Core Information Model -- Version 1 Specification", Work in Progress.
[7] Strassner, John, et al, "Policy Framework LDAP Core Schema",
Work in Progress.
[7] Strassner, John, et al, "Policy Framework LDAP Core Schema", Work in Progress.
[8] Farrell, Stephen and Russell Housley, "An Internet Attribute
Certificate Profile for Authorization", Work in Progress.
[8] Farrell, Stephen and Russell Housley, "An Internet Attribute Certificate Profile for Authorization", Work in Progress.
[9] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
Public Key Infrastructure -- Certificate and CRL Profile", RFC
2459, January 1999.
[9] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure -- Certificate and CRL Profile", RFC 2459, January 1999.
[10] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[10] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[11] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April
1997.
[11]RigneyとC.とルーベンとA.とシンプソン、W.とS.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2138(1997年4月)。
Vollbrecht, et al. Informational [Page 31] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [31ページ]情報のRFC2904AAA認可枠組みの2000年8月
[12] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[12] パーキンス、C.、「IP移動性サポート」、RFC2002、1996年10月。
[13] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for
Policy-based Admission Control", RFC 2753, January 2000.
[13]YavatkarとR.とPendarakisとD.とR.ゲラン、「方針ベースの入場コントロールのための枠組み」、RFC2753、2000年1月。
Authors' Addresses
作者のアドレス
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 Mail: jrv@interlinknetworks.com
以下に電話をしてください。 +1 734 821、1205Fax: +1 1235が郵送する734 821: jrv@interlinknetworks.com
Pat R. Calhoun Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA
パットR.カルフーンネットワークとセキュリティリサーチセンター、サン・マイクロシステムズ・インク15がネットワークでつなぐSun研究室はメンローパーク、カリフォルニア94025米国を旋回します。
Phone: +1 650 786 7733 Fax: +1 650 786 6445 EMail: pcalhoun@eng.sun.com
以下に電話をしてください。 +1 650 786、7733Fax: +1 6445年の650 786メール: pcalhoun@eng.sun.com
Stephen Farrell Baltimore Technologies 61 Fitzwilliam Lane Dublin 2 Ireland
スティーブンファレルボルチモア技術61フィッツウィリアムレーンダブリン2アイルランド
Phone: +353 1 647 7406 Fax: +353 1 647 7499 EMail: stephen.farrell@baltimore.ie
以下に電話をしてください。 +353 1 647 7406Fax: +353 1 647 7499はメールされます: stephen.farrell@baltimore.ie
Vollbrecht, et al. Informational [Page 32] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [32ページ]情報のRFC2904AAA認可枠組みの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
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
Betty de Bruijn Interpay Nederland B.V. Eendrachtlaan 315 3526 LB Utrecht The Netherlands
ベティde Bruijn InterpayネーデルラントB.V.Eendrachtlaan315 3526LBユトレヒトオランダ
Phone: +31 30 2835104 EMail: betty@euronet.nl
以下に電話をしてください。 +31 30 2835104はメールされます: betty@euronet.nl
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
Vollbrecht, et al. Informational [Page 33] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [33ページ]情報のRFC2904AAA認可枠組みの2000年8月
Matt Holdrege ipVerse 223 Ximeno Ave. Long Beach, CA 90803
マットHoldrege ipVerse223Ximeno Ave。 ロングビーチ、カリフォルニア 90803
EMail: matt@ipverse.com
メール: matt@ipverse.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
Vollbrecht, et al. Informational [Page 34] RFC 2904 AAA Authorization Framework August 2000
Vollbrecht、他 [34ページ]情報のRFC2904AAA認可枠組みの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機能のための基金は現在、インターネット協会によって提供されます。
Vollbrecht, et al. Informational [Page 35]
Vollbrecht、他 情報[35ページ]
一覧
スポンサーリンク
