[要約] RFC 2904は、AAA（認証、認可、会計）のための認可フレームワークを提供し、ネットワークリソースへのアクセス制御を強化することを目的としています。
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
AAA認証フレームワーク
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.
Copyright（c）The Internet Society（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プロトコルの承認要件を扱うAAARACH RGが検討している一連の3つのドキュメントの1つです。3つのドキュメントは次のとおりです。
AAA Authorization Framework (this document) AAA Authorization Requirements [2] AAA Authorization Application Examples [3]
AAA認証フレームワーク（このドキュメント）AAA認定要件[2] AAA認定申請の例[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.
この作業は、将来、より包括的なモデルに拡張される可能性があり、ここで説明するスキームは、認証、会計、監査を含むフレームワークに組み込まれると予想しています。多くの承認源を参照しましたが、見逃したものがある可能性があり、含めるべきであることも認識しています。そのような監視の著者の1人に、将来の改訂で修正できるように、著者の1人に通知してください。
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ワーキンググループの憲章がMobileIPおよびNASの要件に焦点を当てるように変更されたとき、AAAARCH Research GroupはIRTF内でチャーターされ、Authorizationサブグループが開始したアーキテクチャ作業を継続および拡大しました。このメモは、サブグループによって作成された4つのメモの1つです。このメモは、AAARACH Research Group内でのさらなる作業の出発点です。これはまだ進行中の作業であり、AAAARCHサブグループやこの分野で働いている他の人々がアーキテクチャや要件の決定的な説明としてではなく、作業が利用可能になるように公開されています。
This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their negatives, in the way described in RFC 2119 [4].
このドキュメントでは、RFC 2119 [4]で説明されている方法で、「必須」、「必要」、「may」、およびそれらのネガティブという用語を使用します。
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. サービスまたはリソースへのアクセスを望むユーザー。
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. サービス自体を提供するサービスプロバイダーのサービス機器。これは、たとえば、ダイヤルサービスのNAS、QoSサービスのルーター、またはインターネット印刷サービスの印刷サーバーである場合があります。
+------+ +-------------------------+
| | | 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時から午前11時の間にサービスにアクセスできる場合があります）。ユーザーホーム組織は、サービスプロバイダーと契約を結んでいます（たとえば、日曜日の午前5時から午前10時の間を除き、アクセスのすべての要求が許可されることを許可されます）。ユーザーの要求の履行は、両方の契約が尊重されることに依存します。
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など）、証明書当局を介して、共有秘密またはパスワードを構成すること、または共通の施設（プロセッサ間の接続ワイヤなど）を共有することにより確立されます。これらの「静的な」信頼関係は、承認取引が行われるために必要です。静的信頼関係は、ユーザーとサービス機器の間に「動的な」関係を確立するための承認シーケンスで使用されます。いくつかの可能な承認シーケンスが可能であり、それぞれがStatic Trust「チェーン」を使用して、ユーザーをユーザーホーム組織によって最初に承認し、次にサービスプロバイダーにユーザーホーム組織の信頼に基づいてリクエストを受け入れさせます。
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).
エージェントシーケンス（図3を参照）では、サービスプロバイダーAAAサーバーは、ユーザーとサービス自体の間のエージェントとして機能します。AAAサーバーは、ユーザーからリクエストを受信し、承認と場合によっては構成情報をサービス機器に転送します。このモデルでは、ユーザーはサービスプロバイダーのAAAサーバー（1）にリクエストを送信します。これは、ユーザーに関連付けられたポリシーと要求されている特定のサービスを適用します。AAAサーバーはサービス機器にリクエストを送信し、サービス機器は要求されたものをすべてセットアップします（2）。その後、サービス機器は、ユーザー向けのサービスをセットアップしたことを認めてAAAサーバーに応答します（3）。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 MB/sの帯域幅（1）を要求する場合があります。帯域幅ブローカー（AAAサーバー）は、ルーター（サービス機器）にこのユーザーを1MB/sの「キュー」（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提案で使用されるものです。ユーザーはサービス機器（1）にリクエストを送信します。これは、サービスプロバイダーのAAAサーバー（2）に転送します。ユーザーの準備ができています（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サーバーからチケットまたは証明書を取得することを要求しています。ユーザーがサービスにアクセスできるように（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.
多くの興味深い状況では、ユーザーを承認および認証する組織は、サービスを提供する組織とは異なります。この状況は、Roaming Operations（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のエンティティ間の契約は、ユーザーからの要求が最初の組織によって認証および承認され、2番目の組織に転送されることを意味します。ユーザーと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 | +-------------+ | | +-------------+ |
+------+ | | | |
+-------------------+ +-------------------+
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がサービスを承認したという確認を受信する可能性があります。その場合、ORG2がある程度の時間で承認を送信しない場合、ORG1は以前に送信された承認を取り消すことができる必要があります。
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には、そのような可能性の1つに、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.
承認の1つの見解は、認可決定に関心があるのは、各組織のポリシーを評価した結果であるということです。このドキュメントでは、各管理者がユーザー、サービス、またはリクエストの他の属性によってインデックス作成される可能性のあるポリシーを持っている可能性があるという仮定があります。各政権の政策は、他の政権とは独立して定義されています。
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ホップ未満の2MB/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）のいずれかをサポートする場合があり、一般的な認可プロトコルは両方を許可する必要があります。ケース3）は、シャドーイングがAAAプロトコルによってサポートされないように「高価」であると思われるため、これ以上見られません。
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の例は、サービスプロバイダーがユーザーのクリアランスコードのクエリを含むUHOにリクエストを転送する場合です。サービスプロバイダーポリシーには、クリアランスコードへの参照が含まれており、返信の情報はそのポリシーへの入力として使用されます。
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が現在使用可能な特定のリソースがあることを確認するサービスプロバイダーを条件とする承認を承認する場合です。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].
ポリシーは、ポリシーリポジトリからポリシー取得ポイント（PRP）によって取得され、ポリシー決定ポイント（PDP）またはポリシー消費者で評価され、ポリシー執行ポイント（PEP）またはポリシーターゲット[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、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は、モデルのさまざまなポイントで使用できるポリシー要素を示しています。分散サービスでは、許可取引に関与する複数のサービスプロバイダーが存在する場合があり、それぞれが以下に示すポリシー要素として機能する場合があります。
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属性証明書の作業は現在、公開キーインフラストラクチャ（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.
証明書ベースのメカニズムを使用して認可を検討する場合、他の属性（例：役割、アカウント制限など）よりも、エンティティのIDに関心が低いことがよくあります。
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の間のリンクは、ACにリクエスターの公開キー証明書（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はパスポートのようなものと見なすことができます。所有者を識別し、長期間有効である傾向があり、鍛造が困難であり、所有者の身元を確立するための強力な認証プロセスがあります。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発行者の3つのエンティティが関係しています。さらに、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
図14-AC交換の一例
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の1つは優先度の高いユーザーからより多くの帯域幅を要求します。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は、ユーザーがいつでも持つことができる同時セッションの数を制限したい場合があります。これは、サービスプロバイダーがすべての人を食べるインターネットアクセスを提供する場合に特に重要です。ユーザーは多くの人にユーザー名/パスワードを提供し、収益の損失を引き起こす可能性があるため、詐欺の可能性は非常に大きいです。リソース管理により、Home ISP AAAサーバーは、ユーザーがアクティブなときに識別し、NASから終了表示が受信されるまで、またはセッションが期限切れになるまでユーザーの承認要求を拒否することができます。
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.
リソースマネージャーは、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.
リソースマネージャーは、AAAサーバーが必要とするすべてのセッション固有のAAA状態情報を維持しています。その状態情報には、同じセッションを参照する追加のAAA状態情報を持っている他の管理ドメインのピアリソースマネージャーへのポインターが含まれる場合があります。リソースマネージャーは、AAAサーバーのアンカーポイントであり、そのセッションが複数のサービスプロバイダー管理ドメインでネットワークリソースまたはサービスを消費している場合でも、セッションを制御、監視、調整できます。
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) これにより、サービスプロバイダー運用スタッフは、外国サービスプロバイダーの管理境界にまたがるリソースを含む、割り当てられたリソースとサービスのステータスを検査できます。ピアリソースマネージャーは、クロスドメイントラブルチケットの診断を支援するために必要な州の情報サブセットのみを協力して共有します。ネットワークオペレーターは、ユーザーのアクティブな承認の1つを変更または完全にキャンセルすることもできます。
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）と協力しています。リソースマネージャーは、ピアリソースマネージャーとの対話によってサポートされている内部状態情報、おそらく複雑な管理ドメイン情報を維持しています。ポリシーサーバーは、特定のポリシーを評価するときに州の情報を使用できます。
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である場合があります。帯域幅の証券会社は、問題ドメインに固有の他の検索インデックスを使用して、アドレス指定されたPEER 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.
2番目のモードは、AAAサーバーが承認を表す確立されたセッションを既に持っている場合です。セッションの状態には、宛先ピア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.
- データの整合性とエラー検出 - このデータトランスポートプロトコルは、エラー検出に関するパケット廃棄、およびサードパーティの変更に対するデータの整合性保護を含む、基礎となるDatagramネットワークレイヤーサービスを想定しています。
- 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サーバーの間で安全にする必要がある場合があります。セキュリティ要件は、次の1つ以上のもので構成されている場合があります。エンドツーエンドのメッセージの完全性、機密性、リプレイ保護、および非表現です。さらに、中間AAAサーバーが、意図した宛先にメッセージを転送する前に、ローカルポリシーなどの情報をメッセージに追加できることが要件です。また、中間AAAサーバーがそのようなアプリメントされた情報に署名する必要がある場合があります。
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.
この要件は[10]で明確に文書化されています。これは、RADIUSがそのような機能を提供しないため、ローミングネットワークのRADIUSプロトコル[11]の多くの現在の弱点[11]を説明しています。よく知られている攻撃の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やMobileIPなどのワーキンググループは、遅延を減らすためにインターネットトラバーサルを最小限に抑えるための要件を特定しています。これらの要件をサポートするために、認証と承認の両方に必要なデータフィールドは、単一のメッセージセットで携帯できる必要があります。これは、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).
エンドツーエンドの認証と承認が発生するためには、ブローカーが証明書当局として行動する必要がある場合があります。ローミングコンソーシアムのすべてのメンバーは、証明書を使用して（ある程度）お互いを信頼することができます。ブローカーにリクエストを送信するサービスプロバイダーのAAAサーバーは、2人のピア（サービスプロバイダーとUHO）が直接対話できるようにするリダイレクトメッセージを受信できる必要があります。ブローカーからのリダイレクトメッセージには、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.
プロキシが必要な場合は、承認プロトコルが中間の攻撃の影響を受けにくい必要はありません。
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サーバーのコンポーネント。
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] Bradner、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] Farrell、S.、Vollebrecht、J.、Calhoun、P.、Gommans、L.、Gross、G.、De Bruijn、B.、De Laat、C.、Holdrege、M。and D. Spence、 "AAA認定要件"、RFC 2906、2000年8月。
[3] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Application Examples", RFC 2905, August 2000.
[3] Vollbrecht、J.、Calhoun、P.、Farrell、S.、Gommans、L.、Gross、G.、De Bruijn、B.、De Laat、C.、Holdrege、M。and D. Spence、 "AAA認証申請書例」、RFC 2905、2000年8月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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、John、Ed Ellesson、およびBob Moore、「ポリシーコア情報モデル - バージョン1仕様」、作業進行中。
[7] Strassner, John, et al, "Policy Framework LDAP Core Schema", Work in Progress.
[7] Strassner、John、et al、「ポリシーフレームワークLDAPコアスキーマ」、進行中の作業。
[8] Farrell, Stephen and Russell Housley, "An Internet Attribute Certificate Profile for Authorization", Work in Progress.
[8] ファレル、スティーブン、ラッセル・ヒューズリーは、「承認のためのインターネット属性証明書プロファイル」で進行中の作業。
[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公開キーインフラストラクチャ - 証明書と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.、Rubens、A.、Simpson、W。and S. Willens、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2138、1997年4月。
[12] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[12] Perkins、C。、「IP Mobility Support」、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。and R. Guerin、「政策ベースの入場管理の枠組み」、RFC 2753、2000年1月。
Authors' Addresses
著者のアドレス
John R. Vollbrecht Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA
John R. Vollbrecht Interlink Networks、Inc。775 Technology Drive、Suite 200 Ann Arbor、MI 48108 USA
Phone: +1 734 821 1205
Fax: +1 734 821 1235
Mail: jrv@interlinknetworks.com
Pat R. Calhoun Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA
PAT R. Calhoun Network and Security Research Center、Sun Labs Sun Microsystems、Inc。15 Network Circle Menlo Park、カリフォルニア、94025 USA
Phone: +1 650 786 7733
Fax: +1 650 786 6445
EMail: 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 Leon Gommans Enterasys Networks EMEA Kerkplein 24 2841 XM Moordrecht The Netherlands
電話：353 1 647 7406 FAX：353 1 647 7499メール：stephen.farrell@baltimore.ie leon gommans enterasysネットワークEmea kerkplein 24 2841 xm Moordrecht The Notherlands
Phone: +31 182 379279
email: gommans@cabletron.com
or at University of Utrecht:
l.h.m.gommans@phys.uu.nl
George M. Gross Lucent Technologies 184 Liberty Corner Road, m.s. LC2N-D13 Warren, NJ 07059 USA
George M. Gross Lucent Technologies 184 Liberty Corner Road、M.S。LC2N-D13 WARREN、NJ 07059 USA
Phone: +1 908 580 4589
Fax: +1 908-580-4991
Email: gmgross@lucent.com
Betty de Bruijn Interpay Nederland B.V. Eendrachtlaan 315 3526 LB Utrecht The Netherlands
Betty de Bruijn Interpay Nederland B.V. Eendrachtlaan 315 3526 lb Utrecht The Netherlands
Phone: +31 30 2835104
EMail: betty@euronet.nl
Cees T.A.M. de Laat Physics and Astronomy dept. Utrecht University Pincetonplein 5, 3584CC Utrecht Netherlands
CEES T.A.M.デラート物理学と天文学部。ユトレヒト大学ピンセトンプリン5、3584ccユトレヒトオランダ
Phone: +31 30 2534585 Phone: +31 30 2537555 EMail: delaat@phys.uu.nl Matt Holdrege ipVerse 223 Ximeno Ave. Long Beach, CA 90803
電話：31 30 2534585電話：31 30 2537555メール：delaat@phys.uu.nl Matt Holdrege Ipverse 223 Ximeno Ave. Long Beach、CA 90803
EMail: matt@ipverse.com
David W. Spence Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA
David W. Spence Interlink Networks、Inc。775 Technology Drive、Suite 200 Ann Arbor、MI 48108 USA
Phone: +1 734 821 1203
Fax: +1 734 821 1235
EMail: dspence@interlinknetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。