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
AAA Authorization Framework
Status of this 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.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
このメモは、インターネットリソースとサービスの認可のための基本要件（AIRS）として機能します。これは、インターネットリソースとサービスの認可を理解するためのアーキテクチャフレームワークを提示し、承認プロトコルの要件を導出します。
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
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つの文書のシリーズの一つです。 3つの文書は以下のとおりです。
AAA Authorization Framework (this document)
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].
認証を提供するすべてのインターネットサービスをカバーし、共通のスキームの立証が必要です。この共通のスキームは、基本的なサービスの要件を満たす様々な機能アーキテクチャに対処します。私たちは、[2]認証プロトコルのための要件を導出するための基礎として、これらのアーキテクチャと機能を説明しようとします。
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.
これらのアーキテクチャは、ポリシー構造、認証局、リソースマネージャ、ドメイン間およびマルチドメインのスキーム、および分散サービスが含まれます。要件は、これらのアーキテクチャ間で認証サービスの予想される使用するためのものです。
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ワーキンググループの認証サブグループだったグループによって行われました。 AAAワーキンググループのチャーターはモバイルIPとNASの要件に焦点を当てるように変更された場合は、AAAarch研究グループは、承認サブグループによって開始された建築作業を継続して展開するIRTF以内にチャーターされました。このメモは、サブグループによって作成された4の一つです。このメモはAAAarch研究グループ内でさらなる作業の出発点です。それはまだ進行中の作業で、作業がAAAarchのサブグループではなくアーキテクチャや要件の明確な説明として、この分野で働く他の人のために利用できるようになりますように公開されています。
This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their negatives, in the way described in RFC 2119 [4].
この文書は、RFC 2119で説明したように、用語「MUST」、「SHOULD」と「MAY」と、そのネガを使用しています[4]。
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は、以下、認可に参加することができる基本的な概念エンティティを識別する。
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.ユーザーユーザーが要求されたサービスやリソースを取得するために許可されているかどうか、ユーザーをチェックして契約を締結しているホーム組織（UHO）。このエンティティは、（クレジット制限など）サービスプロバイダーに知られていない可能性があり、ユーザーを認証するために必要な情報を運ぶことができます。
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.サービスプロバイダのAAAサーバ。この契約は、個々のユーザーに関係のない要素が含まれていてもよい（例えば、合計は、ユーザーのホーム組織とサービスプロバイダ間の帯域幅を合意しました）。
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. Aサービスプロバイダのサービス機器。これは、例えば、ダイヤルサービス、またはQoSサービスでルーター、またはインターネット印刷サービスでは、プリントサーバでNASかもしれません。
+------+ +-------------------------+
| | | User Home Organization |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| |
| |
| |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
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 Home Organization |
| |======| +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| | ||
| | ||
| | ||
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
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図に示すように、契約は、ユーザーのホーム組織（例えば、ユーザーが毎日午前9:00から11:00午前間のサービスへのアクセスを有していてもよい）との契約を持っている、チェーンすることができます。ユーザーのホーム組織は、サービスプロバイダ（例えば、アクセスのためのすべての要求は、日曜日の午前5時00分午前10:00午前の間を除いて、許可されること）との契約を締結しています。ユーザーの要求を満たすことは光栄され、両方の契約に依存します。
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.
これらの契約は、手のコンフィギュレーションにより、またはポリシーデータベースに格納されたポリシーデータの評価によって実現されてもよいことに留意されたいです。ポイントは、許可トランザクションが実行されるためには、エンティティ間の場所で知られている一連のルールがなければならないということです。
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 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.
トラストは、各エンティティは、それが承認されたポリシーが正しいことを「知る」ことができるように必要です。これは、ビジネス上の問題だけでなく、プロトコルの問題です。信託は、しばしば、（Kerberosなど）サードパーティ認証サーバを介して、認証局を介して、共有秘密またはパスワードを設定することにより、又は（例えば、プロセッサ間の接続線のような）共通の機能を共有することによって確立されます。これらの「静的な」信頼関係は場所を取るために、許可取引のために必要です。静的な信頼関係は、ユーザーとサービス機器との間に「動的」な関係を確立するための認証シーケンスで使用されています。いくつかの可能な認証シーケンスは、ユーザが最初にユーザーのホーム組織によって承認され、その後、サービスプロバイダは、ユーザーのホーム組織のその信頼に基づいて要求を受け入れる持つことが持っている静的な信頼「チェーン」を使用し、それぞれが、可能です。
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.
一般的には、ユーザーのホーム組織とサービスプロバイダは、異なるエンティティまたは別の「管理ドメイン」です。最も単純なケースでは、しかし、ユーザーのホーム組織とサービスプロバイダは、単一のエンティティとして組み合わせることができます。この場合は、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サーバおよびサービス機器（分散サービスのように）で、各（ローミングのように）別のユーザーのホーム組織とサービスプロバイダのエンティティと複数のサービスプロバイダを含むより複雑な場合に適用されます。
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.
この場合は、ユーザー、サービスプロバイダのAAAサーバ、およびサービスプロバイダのサービス機器が含まれています。この場合の例としては、スタンドアロンのRADIUSサーバでサポートされているNAS、またはローカル帯域ブローカーによってサポートされるQoSルータが含まれます。
The sequences considered in the following figures are the "agent", "pull", and "push" sequences for the single domain case.
次の図に考慮さシーケンスは、単一のドメインの場合の「薬」、「プル」、および「プッシュ」配列です。
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).
エージェント・シーケンスでは、ユーザーとサービス自体の間でエージェントとして、サービスプロバイダーAAAサーバ機能（図3参照）。 AAAサーバはユーザからの要求やサービス機器に転送許可およびおそらく設定情報を受け取ります。このモデルでは、ユーザーは、ユーザーと要求されている特定のサービスに関連付けられたポリシーを適用するサービスプロバイダのAAAサーバ（1）に要求を送信します。 AAAサーバは、サービス設備への要求を送信し、サービス機器は、（2）要求されているものは何でも設定します。サービス機器は、それはユーザー（3）のサービスを設定していることを認めAAAサーバに応答します。 AAAサーバは、サービスが設定されていること、それを伝えるのユーザーに返信する（4）。
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.
サービスの性質に応じて、更なる通信は、ユーザとサービス機器との間で行われてもよいです。そのためには、ユーザと認定サービス間の結合が必要です。これは、さらなる研究が必要です。
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 4 | +-------------------+ |
| User | | | /|\ |
| | | |2 |3 |
| | | \|/ | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
+------+ | |
+-------------------------+
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).
例：正規ユーザが1メガビット/秒の帯域幅を求めることができる（1）。帯域ブローカー（AAAサーバ）は1MB /秒「キュー」に、このユーザーを設定するには、ルータ（サービス機器）に指示します（2）。ルータは、（3）そうしたことに応答し、帯域ブローカーは、帯域幅が（4）に設定されているユーザーに伝えます。
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）は、典型的には、モバイルIPの提案では、一部のQoSの提案では、ダイヤルイン・アプリケーションで使用されるものです。ユーザーは、要求を評価し、サービスを設定し、伝えるサービス機器（3）への適切な応答を返すサービスプロバイダのAAAサーバ（2）に転送するサービス設備（1）、にリクエストを送信しますユーザー、それは準備ができている（4）。
+-------------------------+
+------+ | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| User | | /|\ | |
| | | |2 |3 |
| | | | \|/ |
| | 1 | +-------------------+ |
| |------+->| Service | |
| |<-----+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
Fig. 4 -- Pull Sequence
図4 - シーケンスを引き
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）ユーザーは、サービスプロバイダーのAAAサーバからそれがo.k.であることを確認し、チケットや証明書を取得する必要がありユーザーのためのサービス（1,2）へのアクセス権を持っています。ユーザーは、サービス設備への要求（3）でチケットを含んでいます。サービス機器は、要求がサービスプロバイダのAAAサーバによって承認されていることを確認するためにチケットを使用しています。サービス機器は、o.k.を送信しますユーザー（4）へ。
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.
ユーザーがサービスプロバイダのAAAサーバから取得するチケットは、一般的にそれにいくつかの時間制限があります。これは、サービスの場所の表示を含むことができ、そしていくつかのアプリケーションでは、複数の要求のために使用される可能性があります。
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サーバとサービス機器間の通信は、自分たちの間でユーザーのではなく、直接を通じて中継されます。
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 2 | +-------------------+ |
| User | | |
| | | |
| | | |
| | 3 | +-------------------+ |
| |------+->| Service | |
| |<-----+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
Fig. 5 -- Push Sequence
図5 - プッシュシーケンス
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.
多くの興味深い状況では、ユーザーを認証し、認証組織がサービスを提供する組織は異なっています。この状況は、ローミング事業（ROAMOPS）ワーキンググループで検討されてきました。サービスプロバイダがローミングしていると考えられるから、この議論の目的のために、どのような状況は、ユーザのホーム組織が異なっています。
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.
ローミングの例としては、他の組織への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.
同じエージェントは、プルとプッシュのシーケンスは、ローミングで可能です。サービスプロバイダのAAAサーバとサービス機器は、説明の目的のための論理エンティティとしてグループ化されている場合は、次の図は、これらの例を説明します。
+------+ +-------------------------+
| | 1 | User Home Organization |
| |----->| +-------------------+ |
| | | | AAA Server | |
| |<-----| | | |
| | 4 | +-------------------+ |
| | | |
| | +-------------------------+
| | | /|\
| | |2 |3
| | \|/ |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 6 -- Roaming Agent Sequence
図6 - 。ローミングエージェントのシーケンス
+------+ +-------------------------+
| | | User Home Organization |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| | /|\ |
| | |2 |3
| | | \|/
| | +-------------------------+
| | | Service Provider |
| User | | +-------------------+ |
| | | | AAA Server | |
| | 1 | | | |
| |----->| +-------------------+ |
| | | |
| |<-----| +-------------------+ |
| | 4 | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 7 -- Roaming Pull Sequence
図7 - プルシーケンスローミング
+------+ +-------------------------+
| | 1 | User Home Organization |
| |----->| +-------------------+ |
| | | | AAA Server | |
| |<-----| | | |
| | 2 | +-------------------+ |
| | | |
| | +-------------------------+
| |
| |
| |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | 3 | | | |
| |----->| +-------------------+ |
| | | |
| |<-----| +-------------------+ |
| | 4 | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 8 -- Roaming Push Sequence
図8 - ローミングプッシュシーケンス
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サービスを必要とするユーザーになります。コンサートで動作する複数のサービスプロバイダによって提供されているすべてのサービスは、分散型サービスです。図9は、分散サービスを示します。
+-------------------+ +-------------------+
+------+ | Org1 | | Org2 |
| | | +-------------+ | | +-------------+ |
| | | | AAA Server | | | | AAA Server | |
| | | | | | | | | |
| | | +-------------+ | | +-------------+ |
| User |======| |======| |
| | | +-------------+ | | +-------------+ |
| | | | Service | | | | Service | |
| | | | Equipment | | | | Equipment | |
| | | +-------------+ | | +-------------+ |
+------+ | | | |
+-------------------+ +-------------------+
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のエンティティ間の契約は、ユーザからの要求が第二組織に転送次に、第一組織によって認証および承認されることを意味します。ユーザとORG1間の配列は、ORG1およびORG2の間で異なってもよいことに留意されたいです。最初はプルシーケンスを使用する場合があり、第二は、エージェント・シーケンスを使用する場合があります。この例は、図10に示されています。
+-------------------+ +-------------------+
+------+ | Org1 | | Org2 |
| | | +-------------+ | 3 | +-------------+ |
| | | | AAA Server |--+------+->| AAA Server | |
| | | | |<-+------+--| | |
| | | +-------------+ | 6 | +-------------+ |
| User | | /|\ | | | | /|\ |
| | | |2 |7 | | |4 |5 |
| | | | \|/ | | \|/ | |
| | 1 | +-------------+ | | +-------------+ |
| |------+->| Service | | | | Service | |
| |<-----+--| Equipment | | | | Equipment | |
| | 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.
分散サービスの認証シーケンスを設定することができ、他のいくつかの方法があります。例えば、セッションをセットアップするには、遅延時間を短縮するために、ORG1がORG2がサービスを承認した検証を受ける前に、ユーザへの応答を送信することができ、ということも可能です。その場合、ORG1はORG2は、ある程度の時間に許可を送信しない場合、以前送られた許可を取り消すことができるようにする必要があります。
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は、ローミングおよび分散サービスの組み合わせを示します。契約と信頼関係は、様々な要因、特にビジネスモデルに応じて、いくつかの方法で設定することができます。
+------+ +-------------------+ +-------------------+
| | | User Home Org | | SuperOrg |
| | | +-------------+ | | +-------------+ |
| | | | AAA Server | | | | AAA Server | |
| | | | | | | | | |
| | | +-------------+ | | +-------------+ |
| | | | | |
| | +-------------------+ +-------------------+
| |
| |
| | +-------------------+ +-------------------+
| User | | Org1 | | Org2 |
| | | +-------------+ | | +-------------+ |
| | | | AAA Server | | | | AAA Server | |
| | | | | | | | | |
| | | +-------------+ | | +-------------+ |
| | | | | |
| | | +-------------+ | | +-------------+ |
| | | | Service | | | | Service | |
| | | | Equipment | | | | Equipment | |
| | | +-------------+ | | +-------------+ |
| | | | | |
+------+ +-------------------+ +-------------------+
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.
組み合わせたり、機能を追加新しいエンティティは、ビジネスニーズを満たすために作成することができます。図11に、そのような可能性は、SuperOrgエンティティが示されています。アイデアは、このエンティティは、エンドユーザーにサービスを提供している組織の認証および認可を提供することです。卸売業者やブローカーであると考えることができます。いないすべての許可がブローカーを持つ必要がありますが、認証プロトコルは、このような事業体が正当な要件を満たすために作成することができるようにする必要があります。
Having considered the basic players and how they interact, we will now consider different ways that authorization data may be stored in the network.
基本的な選手とどのようにそれらが相互作用を検討した、我々は今、認証データをネットワークに保存することができるさまざまな方法を検討します。
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.
ポリシーフレームワーク（ポリシー）ワーキンググループは、表現し、管理、およびベンダーに依存し、相互運用可能、スケーラブルな方法でポリシーとポリシー情報を共有するためのフレームワークを提供しようとしています。 [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.
承認の一つのビューは、それが承認決定に興味を持っている各団体の政策を評価した結果であるということです。本書では仮定は、各投与は、ユーザによって、サービスによって、またはリクエストの他の属性によって索引付けすることができるポリシーを有し得ることです。各投与の政策は互いに独立行政の定義されています。
Each independent policy must be 1) retrieved, 2) evaluated, and 3) enforced.
各独立したポリシーを検索1）でなければならない、2）評価、および3）施行。
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.
ポリシー定義は、それらを必要とする組織[5]によって（または代わりに）、ポリシーリポジトリに保持されて記憶されます。ポリシーフレームワークWGは、ポリシーを記述するための方法に取り組んでいる[7]。他の実装は、ACLリストのセットとして方針を記述します。ポリシーの定義が評価され、施行されるために取得する必要があります。ポリシーの定義は、依頼者によって、サービスの属性によって、または他のいくつかのキーによってインデックス付けすることができます。ポリシーを必要とする組織は、特定の認証要求に適用されるポリシーを決定する責任があります。
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.
ポリシー検索は、典型的には、ポリシーを定義投与により、またはその投与のために作用する薬剤によって行われます。したがって、特定のユーザがネットワークに接続を許可された日の時間を定義するポリシーを維持し、ユーザー組織によって取得されます。メンテナンス維持され、サービスプロバイダによって取得ので、ポートが使用できなくなり、時間を規定するポリシー。
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 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.
いくつかの実装では、サービスプロバイダを持っていることを選択する分散ディレクトリアクセスプロトコルを使用してユーザーのホーム組織からポリシーを検索してもよいことに注意してください。これは、いくつかのケースでは適切ではなく、一般的な解決策ではありませんがあります。理由を理解するには、リモート管理およびホーム政権が彼らの通信をプロキシブローカーを介して通信するとします。この場合、リモートおよびホームの投与は事前の関係を持っていないので、ホームの管理ディレクトリには、リモート管理、およびその逆によってアクセスのためにオープンになることはほとんどありません。
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).
政策の評価は、ポリシーによって参照される情報にアクセスする必要があります。多くの場合、必要な情報には、ポリシーが取得される行政では使用できません。たとえば、ユーザーがユーザーのホーム組織は、現在の時間へのアクセス権を持っているので、容易にユーザーのホーム組織によって行うことができ、現在の時刻にログインを許可されていることを確認します。しかし、以下の4つのホップと2Mビット/ sのパスを必要とするユーザーを認証すると、サービスプロバイダで利用可能とUHOへ直接入手できない情報を必要としUHOは、どちらか1）必要な情報のためのリモート管理を照会する方法を持っている必要がありますので、または2）リモート管理にポリシーを転送し、実際の評価を行うか、3））何とか「影」サービスプロバイダを持つことにより、例えば、情報の信頼できるソース（にUHOに更新を送信しようとするリモート管理を持っています。
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.
サービスプロバイダは、ユーザのクリアランスコードのクエリを含むUHOに要求を転送するときケース1の例です。サービスプロバイダポリシーは、クリアランス・コードおよび応答内の情報への参照は、そのポリシーへの入力として使用される含みます。
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.
UHOは、サービスプロバイダーは、現在、使用可能な特定のリソースがあることを確認した上で、条件付き許可を承認する際にケース2の例があります。 UHOは、サービスプロバイダへの条件付き承認と一緒に「ポリシー」を含みます。
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.
ポリシー施行は通常、サービス機器のサービスプロバイダによって行われます。サービス機器は、ポリシー標的に相当するポリシーフレームワーク[5]で説明。したがって、NASは、「フィルター」を経由して、宛先IPアドレスの制限を強制することができ、ルータは、着信パケットのQoS制限を課す場合があります。サービス機器やサービスプロバイダーAAAサーバとの間で情報を送信プロトコルは、サービス設備に特異的であってもよいが、要件が他のAAAサーバとの間で必要とされるものとは種類の異なるではないようです。
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サーバは、機器が様々な状況の下で何をすべきかを知らせるサービス機器への「ポリシー」を送信することができます。サービス機器は、いずれかのポリシーを「強制」または要求を拒否するように設定する必要があります。
The AAA Server could also send a query to the Service Equipment for information it requires to evaluate a policy.
AAAサーバはまた、政策を評価するために必要な情報のためのサービス機器にクエリを送信することができます。
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].
ポリシーは、ポリシー施行点（PEP）またはポリシー標的でポリシー決定ポイント（PDP）又はポリシー消費者に評価され、ポリシーリポジトリからのポリシーの取得ポイント（PRP）によって取得され、適用される[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サーバのいずれかがポリシーを取得またはポリシーを評価し、サービス機器のいずれかがポリシーを適用することがあります。ポリシーリポジトリは、AAAサーバのいずれかの上に存在し得るか、または他の場所でネットワークに配置します。
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?
そのポリシー条件に対する情報は、（リソースの状態、セッション状態、または一日の時間として）ポリシー情報ポイント（PIPの）でアクセス可能であり、政策情報ブロック（PIBの）を使用してアクセスされる可能性が評価されます。 PDPの、PRPの、のPIPとのPEPがどこにあるかポリシーを使用する任意の認証アプリケーションで興味深い質問はありますか？
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に示す図。分散サービスでは、承認の取引に関与する複数のサービスプロバイダがあってもよく、それぞれ、以下に示すポリシー要素として作用することができます。
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).
ユーザー（または要求者）も、PRP（例えば要求されているサービスを指定するには、ポリシーの記述を使用）、PIP（彼らの政策を評価するために、他のエンティティが必要とする情報を持っている）、及びPDPそれがする場合（決定であってもよいことに注意してください）特定のパラメータを持つサービスを受け入れます。
+------+ +------------------------------+
| | | User Home Organization |
| | | +-------------------+ PRP |
| | | | AAA Server | PIP |
| | | | | PDP |
| | | +-------------------+ |
| | | |
| | +------------------------------+
| |
| |
| | +------------------------------+
| User | | Service Provider |
| | | +-------------------+ PRP |
| PRP | | | AAA Server | PIP |
| PIP | | | | PDP |
| PDP | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | PIP |
| | | | Equipment | PEP |
| | | +-------------------+ |
| | | |
+------+ +------------------------------+
PRP = Policy Retrieval Point PIP = Policy Information Point PDP = Policy Decision Point PEP = Policy Enforcement Point
PRP =ポリシーの取得ポイントPIP =ポリシー情報ポイントPDP =ポリシー決定ポイントPEP =ポリシー実行ポイント
Fig. 12 -- Where Different Policy Elements May be Located
図12 - 異なるポリシーの要素を配置することができます
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プロトコルは、ポリシー定義とポリシーを評価するために必要な情報の両方を運ぶことができなければなりません。また、ポリシー情報のためのクエリをサポートしている必要があります。
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属性証明書の作業は現在、[8]公開鍵基盤（PKIX）ワーキンググループで行われています。この提案は、主にその作業に基づいています。
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は、多くの場合、承認決定を行うために使用されなければならないいくつかの他の属性、（例えば役割、アカウントの制限など）、よりも実体のアイデンティティにはあまり興味を持っています。
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.
多くのこのような場合には、管理、セキュリティ、相互運用性や他の理由のためのアイデンティティからこの情報を分離することをお勧めします。しかし、この認証情報は、公開鍵証明書と同様の方法で保護する必要があるかもしれません。このような構造のために、ここで使用される名前は、属性の属性のデジタル署名された（認定）に設定されている証明書（AC）です。
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.
ACは、主な違いは、それは公開鍵が含まれていないことであるとX.509公開鍵証明書[9]に類似している構造です。 ACは、通常、グループのメンバーシップ、役割、クリアランスとACの所有者に関連する他のアクセス制御情報が含まれています。 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.
ACに基づいてアクセス判定を行う場合、（PEP、PDP又は他の場所で）アクセス決定機能は、適切なACの所有者がアクセスを要求しているエンティティであることを確認する必要があるかもしれません。 ACは、依頼者のための公開鍵証明書（PKC）への「ポインタ」を持っている場合、要求とAC間の連携を実現することができ、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は、パスポートのようなものと考えることができる。それは、所有者を特定し、それが長期間有効である傾向があり、偽造が困難であり、それは所有者のアイデンティティを確立するために強力な認証プロセスを持っています。それは通常、旅券発行機関とは異なる機関によって発行されている点でACは、より多くの入国ビザのようなもので、それはパスポートと同じくらい長い有効期間を持っていません。入国ビザを取得することは一般的にその所有者の身元を認証パスポートを提示する必要があり。その結果、入国ビザを取得することは単純な手順になります。入国ビザは、ビザはパスポートの所有者が国に入ることを許可されている下の単語を指定する方法の一環として、パスポートを指します。
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は、アプリケーションに安全に認証情報を転送するための手段を提供します。しかし、ACが取り得る可能な通信パスの数があります。
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.
一部の環境では、サーバに「プッシュ」ACへのクライアントのために適しています。これは、クライアントとサーバーのドメイン間の新しい接続が必要とされないことを意味します。また、何の検索負担がパフォーマンスが向上し、サーバに課されていないことを意味します。
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.
他の例では、サーバーと、AC発行者またはリポジトリからクライアントのACを要求するサーバーに対して認証するために、単純にクライアントに適しています。このモデルの主な利点は、それがクライアントとクライアント/サーバプロトコルを変更することなく実施することができることです。また、クライアントの権利ではなく、クライアントの「ホーム」ドメイン内よりも、サーバーのドメイン内で割り当てる必要があるいくつかのドメイン間のケースに適しています。
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.
発生する可能性のある取引所の数があり、三個の関与するエンティティがあります：クライアント、サーバー、およびAC発行者は。またAC検索のためのリポジトリとしてディレクトリサービスの使用をサポートすることができます。
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スキーマは、ACが発見される場合を述べた存在）LDAPです。
+--------------+ +---------------+
| AAA Server/ | | |
| AC Issuer +----+ | Directory |
| | | | |
+--+-----------+ | Server +-------+-------+
| | Acquisition |
|Client | |Server
|Acquisition +----------------------+ |Lookup
| | |
+--+-----------+ +--+----+-------+
| | AC in application | Service |
| User +------------------------+ Equipment/ |
| | protocol | AAA Server |
+--+-----------+ +---------------+
|
| Client Lookup
+--+-----------+
| |
| Directory |
| |
+--------------+
Fig. 13 -- AC Exchanges
図13 - AC交流
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 |
+--------------+ +---------------+
Fig. 14 -- One example of an AC exchange
AC交換の一例 - 図14
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).
図において、ユーザ第一コンタクトAC発行者とアプリケーション・プロトコルにACを組み込みます。サービス機器は、その後、ACを検証し、アクセス決定（この機能は、PEPとPDPの間で分散させることができる）のための基礎として使用しなければなりません。
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.
前のセクションで説明したように認証要求は、サーバのセットを介して連鎖していてもよいです。各サーバは、チェーン内のそれのいずれかの側上のサーバとの契約関係を有することができます。検討されているアプリケーションの多くでは、承認は、私たちがセッションを呼び出して継続的なサービスの確立につながります。認証に関わる各サーバは、セッションの状態を追跡し、必要に応じてセッションへの変更を行なうことができるようにしたいことがあります。この能力を議論することを簡単にするために、我々は、各AAAサーバはリソースマネージャコンポーネントを持っているかもしれないことを前提としています。同じセッションを追跡するリソースマネージャは、セッションへの変更を開始すると、変更が発生したときに他のリソース・マネージャーに通知することができるようにする必要があります。リソースマネージャ間の通信は、認証プロトコルのための要件を作成します。
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 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").
リソース管理の使用の例は、2つのISPを介してQoS経路を設定するユーザであるかもしれない、このパスがアクティブである間、のISPの一方が優先度の高いユーザから複数の帯域幅要求を取得します。 ISPは、優先度の低いユーザーの以前に割り当てられたセッションからいくつかの帯域幅を取ると、新しい要求にそれを与える必要があるかもしれません。これを行うには、認証パスにおける行政のそれぞれが通知され、変更に同意する必要があります（これは「新しい価値を承認する」ことを考えることができます）。
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.
AAA依頼者（ユーザーまたは他のAAAサーバのいずれか）にはいくつかのリソースの場合はAAAサーバの補助金の承認、サーバーは、セッション状態情報を維持する必要があるかもしれません。これは、現在のセッションの状態に基づいて、新たなセッションに関する意思決定を行うために、そしてすべての利害AAAサーバによってセッションの監視を可能にするために使用されます。
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.
各セッションは、各AAAサーバ内で一意である必要がありますセッション識別子によって識別されます。 AAAサーバの間の通信は、セッション識別子を含める必要があります。セッション識別子は、すべてのAAAサーバ間で同じであることが望ましい、そうでない場合は、各サーバーは、独自の識別子に他のサーバーからの識別子をマッピングする必要があります。単一セッション識別子を大幅監査およびセッション制御機能を簡素化します。
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:
AAA行政境界を越えてセッション状態を維持することは、信頼チェーン内の各AAAサーバが同様の状態を維持しなければならない場合は特に、問題の複雑さを増します。これは、ドメイン間のデータベース複製の問題とみなすことができます。プロトコルは、複製された状態の管理を支援するツールが含まれている必要があります。対処すべき問題のいくつかは、次のとおりです。
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）サービス機器は、セッションが終了するか、他の方法で状態を変更したときにそのリソースマネージャに通知することができなければなりません。リソースマネージャは、このセッションの状態を維持し、他のリソースマネージャに通知しなければなりません。
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）のリソースマネージャは、権威ある状態または信頼できるソースが認証チェーン内のすべてのリソースマネージャに転送されている定期的なキープアライブメッセージを送信したことにより、リソースマネージャクエリを持つことでリフレッシュしなければならない各セッションの時間制限を設定する必要があります。 。適切なセッションの寿命を決定することは、特定のリスクの許容可能なレベルに依存するアプリケーションであってもよいです。提供されるサービスは、時間に基づいて課金されている場合は、セッションの寿命が比較的小さくする必要があるかもしれません。サービスは使用状況に請求された場合、寿命が比較的大きいかもしれません。
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）チェーン内のすべてのリソース・マネージャは、セッションを終了する能力を持っている必要があります。これは、認可鎖中に少なくとも隣接するAAAサーバの知識を持っているリソースマネージャが必要です。
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.
リソース管理をどのように使用できるかの例は、PPPダイヤルイン・アプリケーションです。ホームISPは、ユーザーが任意の時点で持つことができる同時セッション数を制限することを望むかもしれません。サービスプロバイダーは、インターネットへのアクセスを食べ放題与えるとき、これは特に重要です。ユーザーは、多くの人に自分のユーザー名/パスワードを提供し、収益の損失が発生する可能性があるため、詐欺の可能性は、非常に大きいです。リソース管理は、ユーザーがアクティブで、終了指示がNASからか、セッションが期限切れになるまで受信されるまで、ユーザのための任意の認証要求を拒否するとき、ホームISPのAAAサーバを識別することができます。
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.
Resource Managerは、AAAサーバまたはサービス機器に関連したセッションの状態を追跡するコンポーネントです。それはまた、（外国の管理ドメイン内に、例えば帯域幅）をセッション（例えばIPアドレス）にリソースを割り当てることができ、セッションにピア・リソース・マネージャによって割り当てられたリソースの使用を追跡することができます。リソース・マネージャは、ユーザが許可されたセッションを取得したり解放することを可能にするインターフェースを提供します。
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.
Resource Managerは、AAAサーバが必要とするすべてのセッション固有のAAAの状態情報を保持します。その状態情報は同じセッションを指す追加のAAA状態情報を有する他の管理ドメイン内のリソースマネージャをピアへのポインタを含むことができます。 Resource Managerは、セッションは、制御、監視、およびそのセッションが複数のサービスプロバイダ管理ドメイン間でネットワークリソースやサービスを消費している場合でもコーディネートすることができ、そこからAAAサーバ内のアンカーポイントです。
The Resource Manager has several important functions:
Resource Managerは、いくつかの重要な機能があります。
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）これは、サービスプロバイダの運用スタッフは、外国サービスプロバイダ管理境界にまたがるリソースを含む割り当てられたリソースとサービスのいずれかの状態を検査することができます。ピアリソースマネージャは、協働し、クロスドメインのトラブルチケットの診断を支援するために必要とされるだけの状態情報のサブセットを共有します。ネットワークオペレータは、変更または完全にユーザーのアクティブな権限のいずれかを取り消すことができます。
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）これは、特定のセッションがキャンセルされたAAAサーバに通知するために、他のリソース・マネージャーから連絡するプロセスです。この情報は、そのセッションについて知っているので、それをキャンセルしなければならない他のピアのリソースマネージャに中継されます。
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）リソース・マネージャは、他の管理ドメインから、ユーザからのプライベート内部AAA成分の同一性および位置を隠蔽します。
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）のリソースマネージャは、「ポリシーサーバ」またはポリシー決定ポイント（PDPの）と協力します。 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.
E）は、2つの異なるアーキテクチャのコンポーネントにリソースマネージャの分離およびポリシーサーバは、各管理ドメインは、そのリソース・マネージャと協働する1つまたは複数のポリシーサーバを有する複数の管理ドメインにまたがる単一のセッションを可能にします。
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リソースマネージャは通常、認可シーケンスのために必要な同じ信頼関係を使用します。独立した関係を確立することは可能ですが、それは推奨されません。
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.
AAAサーバは、確実AAAインフラストラクチャ内の正しい宛先システムまたはプロセスにAAAメッセージを転送する責任があります。 2つのよく知られた例は、ローミングAAAサービスのAAAメッセージを転送し、分散AAAサービスのAAAメッセージを転送しています。同じ原理は、ドメイン内の通信に適用することができます。メッセージ転送は2つのモードのいずれかで行われます。
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.
AAAサーバは、その実際のネットワークアドレスに、アプリケーション固有の方法により解決されなければならない既知の「論理宛先アドレス」を有するピアAAAサーバにメッセージを転送する必要があるとき最初のモードです。典型的には、アプリケーション固有の識別子によってデータベースに転送手順インデックスは、ピアのネットワークアドレスを発見します。例えば、ローミングダイヤルインアプリケーションに、アプリケーション固有の識別子は、NAIであってもよいです。帯域幅の仲介アプリケーションは、アドレス指定されたピア・AAAサーバを選択するために、その問題領域に固有の他の検索インデックスを使用します。アドレス解決手順が正常に完了した後、次に、AAAサーバは、その宛先ネットワークアドレスに関連付けられた接続を介してピアにメッセージを送信します。
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 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.
AAAサーバがすでに承認を表す確立されたセッションを持っているときに、第2のモードがあります。セッションの状態は、宛先ピアAAAサーバ、PDP、PEP、またはユーザーにメッセージを向けるために使用されるアドレス指定およびコンテキストを含んでいます。メッセージは他のセッションのメッセージと多重その宛先ピアへのAAAサーバの接続を介して送信されます。メッセージは、両方のエンドポイントによって理解されるセッション識別子によって修飾されなければなりません。 AAAメッセージの宛先は、イントラ管理ドメイン、またはインター管理ドメインのいずれであってもよいです。前者の場合、宛先プロセスは、AAAサーバと同じシステム上に存在してもよいです。
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.
- ユニキャスト能力 - エンドシステムはセッションのセットアップ/オーバーヘッドメッセージを切断し、すべての潜在的なピアに関する状態情報を維持するのないエンドシステムのオーバーヘッドの最小レイテンシを有する他の任意のエンド・システムにメッセージを送信することができます。
- 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.
- 信頼性の高いデータ転送保証 - エンドシステムが正常にメッセージが要求された領収書をマーク受信した場合、それはアプリケーション固有の応答メッセージに、または他のスタンドアロンの確認メッセージで確認応答をピギーバックのいずれかによって、送信システムにそのメッセージを確認する必要があります。送信システムは、再試行タイマを保持します。タイマーが満了したとき、送信側システムは、元のメッセージのコピーを再送信します。それは失敗し、再試行の設定可能な数の後に断念します。
- 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.
- ネットワーク輻輳フィードバックに応答 - ネットワークが輻輳に入るときに、エンドシステムは、その状態を検出しなければならず、輻輳がおさまるまで、彼らは、伝送レートをバックオフしなければなりません。バックオフと回復アルゴリズムは、振動を避けなければなりません。
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 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.
AAAサーバは、ブローカーなどの中間AAAサーバを介して通信する場合、ペイロードの一部は、発信元と目標AAAサーバの間で安全であることが必要であってもよいです。エンドツーエンドのメッセージの完全性、機密性、再生保護、および否認防止：セキュリティ要件は、次の一つ以上からなるものであってもよいです。また、中間AAAサーバは、その意図された宛先にメッセージを転送する前にメッセージに、ローカルポリシーなどの情報を追加することができることが要件です。また、中間体AAA Serverは、このような付加情報に署名することが要求されてもよいです。
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.
この要求は、明らかにRADIUSは、このような機能を提供しないので、ネットワークをローミングにRADIUSプロトコル[11]の多くの現在の弱点を説明している、[10]に記載されています。 1つのよく知られた攻撃は、セッション時間などの重要な会計上の情報を、修正する中間ノードのための機能です。
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.
最も人気のあるセキュリティプロトコル（例えばなどのIPSec、SSLは、）ペイロードの部分を保護する機能を提供していません。したがって、エンドツーエンドのセキュリティを提供するために、独自のセキュリティ拡張機能を実装するためのAAAプロトコルに必要であり得ます。
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.
上述の技術は、認証および承認のために必要なコンポーネントを配布に大きな柔軟性を可能にします。しかし、このようROAMOPSやモバイルIPなどのワーキンググループは、待ち時間を短縮するために、インターネットトラバーサルを最小限にするための要件を特定しました。これらの要件をサポートするために、認証と認可の両方のために必要なデータフィールドは、設定された単一のメッセージで運ばれることができるべきです。 AAAチェーン内（例えばブローカーなど）の中間サーバがある場合、これは特に重要です。
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.
ブローカーらは、エンド・ツー・エンド（ダイレクト）認証および承認できるようにするためにさらに、それは可能なはずです。これは以下のように行うことができます。ユーザーのホーム組織はUHOの秘密鍵を使って署名されたチケットを生成します。チケットは、アカウンティングメッセージで運ばれます。ブローカーは、決済剤として作用し、この情報を必要としているので、アカウンティングメッセージは、ブローカーを通って流れなければなりません。そこだけでなく、彼らは不正行為を検出するために、この情報を使用しますので、認証と認可のパスにあることが必要になりますブローカーがあるので、上記のオプションでなければなりません。
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 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).
Brokerは認証局として機能するためのエンドツーエンドの認証と認可が発生するためには、それが必要な場合があります。ローミングコンソーシアムのすべてのメンバーは、証明書を使用して（ある程度）お互いを信頼することができるだろう。ブローカにリクエストを送信し、サービスプロバイダのAAAサーバは、2つのピア（サービスプロバイダおよびUHO）が直接対話することができるようになるリダイレクトメッセージを受け取ることができるはずです。ブローカーからのリダイレクトメッセージは、証明書のアーカイブにアクセスするサービス・プロバイダーを排除UHOの証明書を含める必要があります。サービスプロバイダからの要求は、独自の証明書、およびタイムスタンプで、サービスプロバイダは、ブローカーとの良好な状態にあることを保証ブローカーのリダイレクトメッセージからトークンを含めることができます。これは、証明書失効リスト（CRL）にアクセスからホームドメインを排除します。
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.
上記のユーザー、ユーザーのホーム組織、サービスプロバイダのAAAサーバ、およびサービス機器としての認可トランザクションで基本的な選手を発表しました。これは、契約または契約上、および「信頼」に基づくエンティティ間の関係を議論しました。承認配列の例が与えられています。
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.
ローミングの概念と分散サービスについて簡単に説明されています。ローミングおよび分散サービスの組み合わせも考慮され、「問屋」やブローカーの概念が導入されました。私たちは、ポリシーおよび属性証明書の使用が許可データを保存し、送信するために考えられてきました。私たちは、これにセッション指向のサービスのための状態情報を追跡する問題など、許可されたアクセスリソースを管理する問題を議論し、そして我々は、AAAサーバのリソースマネージャコンポーネントを定義しました。私たちは、おそらく異なる管理ドメイン内のサーバー間でAAAメッセージを転送の問題を考えました。当社は、中間AAAサーバを通過する承認メッセージのペイロードの部分のエンドツーエンドのセキュリティの必要性を検討しました。最後に、我々は、レイテンシに敏感なアプリケーションのための遅延を最小限に抑えることが合理承認プロセスのサポートの必要性を強調しました。
The intent is that this will provide support for discussing and understanding requirements of specific applications that need authorization services.
その意図は、これは議論および承認サービスを必要とする特定のアプリケーションの要件を理解するための支援を提供することです。
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 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.
プロキシが必要な場合は、認証プロトコルは、man-in-the-middle攻撃を受けやすいであってはなりません。
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.
エージェントモデルを使用する場合は、許可とサービス自体との間の結合は、不正別によって受信されることから、一方の当事者に認定サービスを防ぐために保護されなければなりません。
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.
迂回に対する保護に加えて、このフレームワークに基づいて設計された認証プロトコルは、いくつかの固有のセキュリティ要件を持つことになります。これらは、[2]における要件の中に含まれ、以下に簡単に要約されています。
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.
固有のセキュリティニーズの中での認証プロトコルは、機密情報を運ぶことができるという事実です。許可決定に関与しても特定の当事者（セクション8で説明したように）を含む不正な当事者に開示からそのような情報を保護する必要があります。
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.
認証は多くのインターネットサービスへのアクセスを得るために必要となりますので、最後に、認証サーバに対するサービス拒否攻撃は、インターネットサービスへのアクセスを防止することで、サービス機器自体に対するサービス拒否攻撃と同じくらい有効であることができます。
Glossary
用語集
Attribute Certificate -- structure containing authorization attributes which is digitally signed using public key cryptography.
属性証明書 - 承認を含有する構造がデジタル公開鍵暗号を使用して署名されている属性。
Contract Relationship -- a relation established between two or more business entities where terms and conditions determine the exchange of goods or services.
契約関係 - 契約条件は、商品やサービスの交換を決定する2つの以上のビジネスエンティティ間で確立関係。
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.
ダイナミックな信頼関係 - 動的に任意の前に関係を持ったことがないかもしれ2つのエンティティ間で作成され、安全な関係。関与するエンティティは、相互に信頼できる第三者を持っている場合、この関係は、作成することができます。例：彼らの両方は、クレジットカードの組織によって知られているので、商人は支払取引時のカード所有者を信頼します。
Policy Decision Point (PDP) -- The point where policy decisions are made.
ポリシー決定ポイント（PDP） - 政策決定がなされるポイント。
Policy Enforcement Point (PEP) -- The point where the policy decisions are actually enforced.
ポリシー実行ポイント（PEP） - 政策決定が実際に施行されているポイント。
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.
リソースマネージャ - AAAサーバまたはそれに関連するサービス機器に関連したセッションの状態を追跡し、セッションは、制御、監視、および調整することができ、そこからアンカーポイントを提供AAA Serverのコンポーネント。
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.)
ローミング - サービスプロバイダーとユーザーのホーム組織が2つの異なる組織で取引する許可を。 （ダイヤルインアプリケーションがローミングが活発に検討されているためいずれかであることに留意されたいが、この定義は、他のアプリケーションを含みます。）
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]
セキュリティ協会は - プロトコルメッセージに適用することができるノードのペア間のセキュリティコンテキストのコレクションは、それらの間で交換しました。各コンテキストは、使用中の認証アルゴリズムおよびモード、シークレット（共有キー、または適切な公開鍵/秘密鍵のペア）、および再生保護のスタイルを示します。 [12]
Service Equipment -- the equipment 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 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.
静的な信頼関係 - 信頼されたパーティが作成した2つのエンティティ間で事前に確立された安全な関係。この関係は、セキュリティやトレーサビリティの一定レベルのAAAメッセージの交換を容易にします。例：ワイヤリングクローゼットへのアクセス権を持つネットワークオペレータ（信頼パーティ）は、ユーザーのコンセントと、特定のネットワークポートとの間の接続を作成します。ユーザは、その後、信頼されている - ある程度 - この特定のネットワークポートに接続されます。
User -- the entity seeking authorization to use a resource or a service.
ユーザー - リソースやサービスを使用する許可を求めているエンティティ。
User Home Organization (UHO) -- An organization with whom the User has a contractual relationship which can authenticate the User and may be able to authorize access to resources or services.
ユーザーのホーム組織（UHO） - ユーザーがユーザーを認証することができ、資源やサービスへのアクセスを許可することができるかもしれ契約関係を持っている人と組織。
References
リファレンス
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[2] 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]ファレル、S.、Vollbrecht、J.、カルフーン、P.、Gommans、Bruijnグラフ、B.、デLAAT、C.、ホールドレッジ、M.とD.スペンスデL.グロス、G.、 " AAA許可の要件」、RFC 2906、2000年8月。
[3] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Application Examples", RFC 2905, August 2000.
[3] Vollbrecht、J.、カルフーン、P.、ファレル、S.、Gommans、Bruijnグラフ、B.、デLAAT、C.、ホールドレッジ、M.とD.スペンスデL.グロス、G.、 " AAA認証アプリケーション例」、RFC 2905、2000年8月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Stevens, M., "Policy Framework", Work in Progress.
[5]スティーブンス、M.、 "ポリシーフレームワーク" が進行中で働いています。
[6] Strassner, John, Ed Ellesson, and Bob Moore, "Policy Core Information Model -- Version 1 Specification", Work in Progress.
[6] Strassner、ジョン、エドEllesson、ボブ・ムーア、「方針コア情報モデル - バージョン1仕様」が進行中で働いています。
[7] Strassner, John, et al, "Policy Framework LDAP Core Schema", Work in Progress.
[7] Strassner、ジョンら、「ポリシーフレームワークLDAPコアスキーマ」が進行中で働いています。
[8] Farrell, Stephen and Russell Housley, "An Internet Attribute Certificate Profile for Authorization", Work in Progress.
[8]ファレル、スティーブン・ラッセルHousley氏、「認可のためのインターネット属性証明書プロフィール」、進行中の作業を。
[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.、フォード、W.、ポーク、W.およびD.ソロ、 "インターネットX.509公開鍵基盤 - 証明書とCRLプロファイル"、RFC 2459、1999年1月。
[10] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[10] Aboba、B.、およびJ. Vollbrecht、 "ローミング中のプロキシ連鎖とポリシー実装"、RFC 2607、1999年6月。
[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. Willens、RFC 2138、1997年4月 "ユーザーサービス（RADIUS）においてリモート認証ダイヤル"。
[12] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[12]パーキンス、C.、 "IPモビリティサポート"、RFC 2002、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.ゲラン、 "ポリシーベースのアドミッション制御のためのフレームワーク"、RFC 2753、2000年1月。
Authors' Addresses
著者のアドレス
John R. Vollbrecht Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA
ジョンR. Vollbrechtインターリンクネットワークス株式会社775テクノロジードライブ、スイート200アナーバー、MI 48108 USA
Phone: +1 734 821 1205 Fax: +1 734 821 1235 Mail: jrv@interlinknetworks.com
電話：+1 734 821 1205ファックス：+1 734 821 1235メール：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.カルフーンネットワークとセキュリティ研究センター、日Labsのサン・マイクロシステムズ株式会社15ネットワークサークルメンロパーク、カリフォルニア、94025 USA
Phone: +1 650 786 7733 Fax: +1 650 786 6445 EMail: pcalhoun@eng.sun.com
電話：+1 650 786 7733ファックス：+1 650 786 6445 Eメール：pcalhoun@eng.sun.com
Stephen Farrell Baltimore Technologies 61 Fitzwilliam Lane Dublin 2 Ireland
スティーブン・ファレルボルチモアテクノロジーズ61フィッツウィリアムレーンダブリンアイルランド
Phone: +353 1 647 7406 Fax: +353 1 647 7499 EMail: stephen.farrell@baltimore.ie
電話：+353 1 647 7406ファックス：+353 1 647 7499 Eメール：stephen.farrell@baltimore.ie
Leon Gommans Enterasys Networks EMEA Kerkplein 24 2841 XM Moordrecht The Netherlands
レオンGommansのEnterasys NetworksのEMEA Kerkplein 24 2841 XMオランダMoordrecht
Phone: +31 182 379279 email: gommans@cabletron.com or at University of Utrecht: l.h.m.gommans@phys.uu.nl
電話：+31 182 379279 Eメール：gommans@cabletron.comやユトレヒト大学：l.h.m.gommans@phys.uu.nl
George M. Gross Lucent Technologies 184 Liberty Corner Road, m.s. LC2N-D13 Warren, NJ 07059 USA
ジョージM.総ルーセント・テクノロジーズ184リバティ・コーナーの道、M.S。 LC2N-D13ウォーレン、NJ 07059 USA
Phone: +1 908 580 4589 Fax: +1 908-580-4991 Email: gmgross@lucent.com
電話：+1 908 580 4589ファックス：+1 908-580-4991電子メール：gmgross@lucent.com
Betty de Bruijn Interpay Nederland B.V. Eendrachtlaan 315 3526 LB Utrecht The Netherlands
ベティ・ド・BruijnグラフInterpayオランダB.V.社Eendrachtlaan 315 3526 LBユトレヒトオランダ
Phone: +31 30 2835104 EMail: betty@euronet.nl
電話：+31 30 2835104 Eメール：betty@euronet.nl
Cees T.A.M. de Laat Physics and Astronomy dept. Utrecht University Pincetonplein 5, 3584CC Utrecht Netherlands
CEES T.A.M.物理学や天文学DEPTをしてみましょう。ユトレヒト大学Pincetonplein 5、3584CCユトレヒトオランダ
Phone: +31 30 2534585 Phone: +31 30 2537555 EMail: delaat@phys.uu.nl
電話：+31 30 2534585電話：+31 30 2537555 Eメール：delaat@phys.uu.nl
Matt Holdrege ipVerse 223 Ximeno Ave. Long Beach, CA 90803
マット・ホールドレッジipVerse 223 Ximenoアベニュー。ロングビーチ、CA 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.スペンスインターリンクネットワークス株式会社775テクノロジードライブ、スイート200アナーバー、MI 48108 USA
Phone: +1 734 821 1203 Fax: +1 734 821 1235 EMail: dspence@interlinknetworks.com
電話：+1 734 821 1203ファックス：+1 734 821 1235 Eメール：dspence@interlinknetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。