[要約] RFC 2905は、AAA認証アプリケーションの実装例を提供するものであり、AAAプロトコルの使用方法を示すことを目的としています。
Network Working Group J. Vollbrecht
Request for Comments: 2905 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 Application Examples
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 describes several examples of applications requiring authorization. Each application is described in terms of a consistent framework, and specific authorization requirements of each application are given. This material was not contributed by the working groups responsible for the applications and should not be considered prescriptive for how the applications will meet their authorization needs. Rather the intent is to explore the fundamental needs of a variety of different applications with the view of compiling a set of requirements that an authorization protocol will need to meet in order to be generally useful.
このメモは、許可を必要とするアプリケーションのいくつかの例について説明しています。各アプリケーションは、一貫したフレームワークの観点から説明されており、各アプリケーションの特定の承認要件が与えられます。この資料は、アプリケーションの責任を負うワーキンググループによって提供されたものではなく、アプリケーションが承認のニーズをどのように満たすかについて規範的と見なされるべきではありません。むしろ、承認プロトコルが一般的に有用になるためには、満たす必要がある一連の要件を編集するという見解を備えた、さまざまなアプリケーションの基本的なニーズを探求することです。
Table of Contents
目次
1. Introduction ................................................ 3
2. PPP Dialin with Roaming ..................................... 4
2.1. Descriptive Model ...................................... 4
2.2. Authorization Requirements ............................. 6
3. Mobile-IP ................................................... 6
3.1. Relationship to the Framework .......................... 10
3.2. Minimized Internet Traversal ........................... 10
3.3. Key Distribution ....................................... 10
3.4. Mobile-IP Authorization Requirements ................... 11
4. Bandwidth Broker ............................................ 12
4.1. Model Description ...................................... 13
4.2. Components of the Two-Tier Model ....................... 13
4.3. Identification of Contractual Relationships ............ 13
4.3.1. Single-Domain Case .............................. 14
4.3.2. Multi-Domain Case ............................... 15
4.4. Identification of Trust Relationships .................. 16
4.5. Communication Models and Trust Relationships ........... 18
4.6. Bandwidth Broker Communication Models .................. 19
4.6.1. Concepts ........................................ 19
4.6.1.1. Intra-Domain Authorization ............... 19
4.6.1.2. Inter-Domain Authorization ............... 19
4.6.2. Bandwidth Broker Work Phases .................... 20
4.6.3. Inter-Domain Signaling .......................... 20
4.6.3.1. Phase 0 .................................. 20
4.6.3.2. Phase 1 .................................. 20
4.6.4. Bandwidth Broker Communication Architecture ..... 22
4.6.5. Two-Tier Inter-Domain Model ..................... 23
4.6.5.1. Session Initialization ................... 23
4.6.5.2. Service Setup ............................ 23
4.6.5.3. Service Cancellation ..................... 24
4.6.5.4. Service Renegotiation .................... 24
4.6.5.5. RAR and RAA .............................. 24
4.6.5.6. Session Maintenance ...................... 24
4.6.5.7. Intra-domain Interface Protocol .......... 24
4.7. Requirements ........................................... 24
5. Internet Printing ........................................... 25
5.1. Trust Relationships .................................... 26
5.2. Use of Attribute Certificates .......................... 27
5.3. IPP and the Authorization Descriptive Model ............ 28
6. Electronic Commerce ......................................... 29
6.1. Model Description ...................................... 30
6.1.1. Identification of Components .................... 30
6.1.2. Identification of Contractual Relationships ..... 31
6.1.3. Identification of Trust Relationships ........... 32
6.1.3.1. Static Trust Relationships ............... 33
6.1.3.2. Dynamic Trust Relationships .............. 35
6.1.4. Communication Model ............................. 35
6.2. Multi Domain Model ..................................... 37
6.3. Requirements ........................................... 38
7. Computer Based Education and Distance Learning .............. 40
7.1. Model Description ...................................... 40
7.1.1. Identification of Components .................... 40
7.1.2. Identification of Contractual Relationships ..... 41
7.1.3. Identification of Trust Relationships ........... 43
7.1.4. Sequence of Requests ............................ 44
7.2. Requirements ........................................... 46
8. Security Considerations ..................................... 47
Glossary ....................................................... 47
References ..................................................... 48
Authors' Addresses ............................................. 50
Full Copyright Statement ....................................... 53
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 [2] AAA Authorization Requirements [3] AAA Authorization Application Examples (this document)
AAA認証フレームワーク[2] AAA認定要件[3] AAA認定申請の例（このドキュメント）
In this memo, we examine several important Internet applications that require authorization. For each application, we present a model showing how it might do authorization and then map that model back to the framework presented in [2]. We then present the authorization requirements of the application as well as we presently understand them. The requirements presented in this memo have been collected together, generalized, and presented in [3].
このメモでは、許可を必要とするいくつかの重要なインターネットアプリケーションを調べます。各アプリケーションについて、[2]で提示されたフレームワークにそのモデルをマッピングする方法を示すモデルを提示します。次に、アプリケーションの承認要件を提示し、現在それらを理解しています。このメモに示されている要件は、一緒に収集され、一般化され、[3]で提示されています。
The intent of this memo is to validate and illustrate the framework presented in [2] and to motivate the requirements presented in [3]. This work is intended to be in alignment with the work of the various working groups responsible for the authorization applications illustrated. This memo should not, however, be regarded as authoritative for any of the applications illustrated. Where authoritative documents exist or are in development, they are listed in the references at the end of this document.
このメモの意図は、[2]で提示されたフレームワークを検証および説明し、[3]で提示された要件を動機付けることです。この作業は、図解された認可アプリケーションを担当するさまざまなワーキンググループの作業と一致することを目的としています。ただし、このメモは、説明されているアプリケーションのいずれかの権威あると見なされるべきではありません。権威ある文書が存在するか、開発中の場合、このドキュメントの最後の参照にリストされています。
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」、およびそれらのネガティブという用語を使用します。
In this section, we present an authorization model for dialin network access in terms of the framework presented in [2]. Included in the model are the multi-domain considerations required for roaming [5]. Detailed requirements for network access protocols are presented in [6].
このセクションでは、[2]で提示されたフレームワークに関して、ダイヤリンネットワークアクセスの認証モデルを提示します。モデルには、ローミングに必要なマルチドメインの考慮事項が含まれています[5]。ネットワークアクセスプロトコルの詳細な要件は[6]に示されています。
The PPP dialin application uses the pull sequence as discussed in [2]. The roaming case uses the roaming pull sequence, also discussed in [2]. This sequence is redrawn using dialin roaming terminology in figure 1, below.
PPPダイヤリンアプリケーションは、[2]で説明したように、プルシーケンスを使用します。ローミングケースは、[2]でも議論されているローミングプルシーケンスを使用します。このシーケンスは、以下の図1にダイヤリンローミング用語を使用して再描画されます。
+------+ +-------------------------+
| | | Home ISP |
| | | (User Home Organization)|
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | /|\ | |
| | +--------------+---+------+
| | | |
| | |3 |4
| | | |
| | +--------------+---+------+
| | | Visited ISP | | |
| | | | \|/ |
| User | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | /|\ | |
| | | |2 |5 |
| | | | \|/ |
| | 1 | +-------------------+ |
| |------+->| NAS (Service | |
| |<-----+--| Equipment) | |
| | 6 | +-------------------+ |
| | | (Service Provider) |
+------+ PPP +-------------------------+
Fig. 1 -- Dialin Authorization Based on Roaming Pull Sequence
図1-ローミングプルシーケンスに基づくダイヤリン承認
In this model, the User dials in to a Network Access Server (NAS) provided by the visited (or foreign) ISP (the Service Provider in the general model). The User is authenticated using a protocol such as PAP, CHAP, or EAP which is encapsulated in PPP frames (1). Because the User has not yet gained access to the network, he or she cannot send IP datagrams to a AAA server. At this point, the User can only communicate with the NAS (Service Equipment). The NAS forwards the User's authentication/ authorization request including the Network Access Identifier (NAI) [7] to a AAA server in its own domain via RADIUS [8] or a successor AAA protocol (2). The visited ISP's AAA server examines the realm from the NAI and forwards the request to the User's home domain AAA server (3). The home domain AAA server authenticates the user and authorizes access according to a roaming agreement. The home domain AAA server may return service parameters (e.g. Idle-Timeout) to the visited ISP's AAA server (4) which forwards them to the NAS, possibly adding additional service parameters (5). The NAS completes PPP session initialization (6).
このモデルでは、ユーザーは、訪問（または外国）ISP（一般モデルのサービスプロバイダー）によって提供されるネットワークアクセスサーバー（NAS）にダイヤルインします。ユーザーは、PPPフレーム（1）にカプセル化されているPAP、CHAP、またはEAPなどのプロトコルを使用して認証されます。ユーザーはまだネットワークへのアクセスを取得していないため、IPデータグラムをAAAサーバーに送信することはできません。この時点で、ユーザーはNAS（サービス機器）とのみ通信できます。NASは、ネットワークアクセス識別子（NAI）[7]を含むユーザーの認証/認証要求を、RADIUS [8]または後継AAAプロトコル（2）を介して独自のドメインのAAAサーバーに転送します。訪問されたISPのAAAサーバーは、NAIの領域を調べ、リクエストをユーザーのホームドメインAAAサーバー（3）に転送します。ホームドメインAAAサーバーは、ユーザーを認証し、ローミング契約に従ってアクセスを許可します。ホームドメインAAAサーバーは、サービスパラメーター（アイドルタイムアウトなど）を訪問したISPのAAAサーバー（4）に戻し、NASに転送し、追加のサービスパラメーターを追加する場合があります（5）。NASはPPPセッションの初期化を完了します（6）。
In the future, this model may be expanded in several ways [9]. For instance, Authentication and Authorization may be done in separate passes using different servers in order to support specialized forms of authentication. Or to better support roaming, a broker may be inserted between the visited ISP and the home ISP. Or authorization may be supported based on other identifiers such as the caller ID and called ID obtained from the PSTN (e.g., using ANI and DNIS).
将来、このモデルはいくつかの方法で拡張される可能性があります[9]。たとえば、認証と承認は、特殊な形式の認証をサポートするために、異なるサーバーを使用して個別のパスで行うことができます。または、ローミングをよりよくサポートするために、ブローカーが訪問したISPとHome ISPの間に挿入される場合があります。または、承認は、発信者IDなどの他の識別子に基づいてサポートされ、PSTNから取得したIDと呼ばれる（ANIおよびDNISを使用するなど）。
The following requirements are identified in [9] for authorizing PPP dialin service using roaming.
ローミングを使用してPPPダイヤリンサービスを承認するために、[9]で以下の要件が特定されています。
- Authorization separate from authentication should be allowed when necessary, but the AAA protocol MUST allow for a single message to request both authentication and authorization.
- 必要に応じて認証とは別の認証を許可する必要がありますが、AAAプロトコルは、認証と承認の両方を要求するための単一のメッセージを許可する必要があります。
- The AAA protocol MUST be "proxyable", meaning that a AAA Server or PDP MUST be able to forward the request to another AAA Server or PDP, which may or may not be within the same administrative domain.
- AAAプロトコルは「プロキシ可能」でなければなりません。つまり、AAAサーバーまたはPDPは、同じ管理領域内にある場合とそうでない場合がある別のAAAサーバーまたはPDPにリクエストを転送できる必要があります。
- The AAA protocol MUST allow for intermediate brokers to add their own local Authorization information to a request or response.
- AAAプロトコルは、中間ブローカーが独自のローカル認証情報をリクエストまたは応答に追加することを許可する必要があります。
- When a broker is involved, the protocol MUST provide end to end security.
- ブローカーが関与している場合、プロトコルはエンドエンドセキュリティを提供する必要があります。
- The broker MUST be able to return a forwarding address to a requester, allowing two nodes to communicate together.
- ブローカーは、転送アドレスをリクエスターに返すことができ、2つのノードが一緒に通信できるようにする必要があります。
- The protocol MUST provide the following features (per user session):
- プロトコルは、次の機能（ユーザーセッションごと）を提供する必要があります。
1. One Authentication, One Authorization 2. One Authentication, Multiple Authorization 3. Multiple Authentication, Multiple Authorization
1. 1つの認証、1つの承認2. 1つの認証、複数の承認3.複数の認証、複数の認証
The Mobile-IP protocol is used to manage mobility of an IP host across IP subnets [10]. Recent activity within the Mobile-IP Working Group has defined the interaction between Mobile-IP and AAA in order to provide:
Mobile-IPプロトコルは、IPサブネットを介したIPホストのモビリティを管理するために使用されます[10]。Mobile-IPワーキンググループ内の最近のアクティビティは、次のようにMobile-IPとAAAの相互作用を定義しました。
- Better scaling of security associations - Mobility across administrative domain boundaries - Dynamic assignment of Home Agent
- セキュリティ協会のより良いスケーリング - 管理ドメインの境界を越えたモビリティ - ホームエージェントの動的な割り当て
The Mobile IP protocol, as defined in [10], works well when all mobile nodes belong to the same administrative domain. Some of the current work within the Mobile IP Working Group is to allow Mobile IP to scale across administrative domains. This changes the trust model that is currently defined in [10].
[10]で定義されているモバイルIPプロトコルは、すべてのモバイルノードが同じ管理ドメインに属している場合にうまく機能します。モバイルIPワーキンググループ内の現在の作業の一部は、モバイルIPが管理ドメイン全体でスケーリングできるようにすることです。これにより、現在[10]で定義されている信頼モデルが変更されます。
The requirements for Mobile-IP authorization are documented in [11]. In this section, we develop a multi-domain model for Mobile-IP authorization and present it in the terms of the framework presented in [2].
モバイルIP認証の要件は[11]に文書化されています。このセクションでは、モバイルIP許可のためのマルチドメインモデルを開発し、[2]で提示されたフレームワークの観点からそれを提示します。
Figure 2 depicts the new AAA trust model for Mobile-IP. In this model each network contains mobile nodes (MN) and a AAA server (AAA). Each mobility device shares a security association (SA) with the AAA server within its own home network. This means that none of the mobility devices initially share a security association. Both administrative domains' AAA servers can either share a security association, or can have a security association with an intermediate broker.
図2は、モバイルIPの新しいAAAトラストモデルを示しています。このモデルでは、各ネットワークにはモバイルノード（MN）とAAAサーバー（AAA）が含まれています。各モビリティデバイスは、独自のホームネットワーク内のAAAサーバーとセキュリティ協会（SA）を共有しています。これは、モビリティデバイスのいずれも最初にセキュリティ協会を共有していないことを意味します。両方の管理ドメインのAAAサーバーは、セキュリティ協会を共有するか、中間ブローカーとセキュリティ協会を持つことができます。
Broker AAA
+--------+
| |
| AAA |
/=====| |=====\
// +--------+ \\
Foreign // SA SA \\ Home
AAA // \\ AAA
+--------+ +--------+
| | SA | |
| AAA |======================| AAA |
| | (in lieu of broker) | |
+--------+ +--------+
|| || ||
SA || SA || || SA
|| || ||
|| || ||
+---------+ +---------+ +---------+
| | | | | |
| FA | | HA | | MN |
| | | | | |
+---------+ +---------+ +---------+
Fig. 2 -- Mobile-IP AAA Trust Model
図2-モバイルIP AAAトラストモデル
Figure 3 provides an example of a Mobile-IP network that includes AAA. In the integrated Mobile-IP/AAA Network, it is assumed that each mobility agent shares a security association between itself and its local AAA server. Further, the Home and Foreign AAA servers both share a security association with the broker's AAA server. Lastly, it is assumed that each mobile node shares a trust relationship with its home AAA Server.
図3は、AAAを含むモバイルIPネットワークの例を示しています。統合されたMobile-IP/AAAネットワークでは、各モビリティエージェントがそれ自体とローカルAAAサーバーとの間のセキュリティ関連を共有していると想定されています。さらに、ホームと外国のAAAサーバーはどちらもブローカーのAAAサーバーとセキュリティ協会を共有しています。最後に、各モバイルノードはホームAAAサーバーと信頼関係を共有していると想定されています。
Visited Access Broker Home IP
Provider Network Network Network
+--------+ +--------+ +--------+
| | | | | |
| AAA |------| AAA |------| AAA |
| | | | | |
+--------+ +--------+ +--------+
| |
| |
AAA | | AAA
| |
| |
+---------+ +---------+
| | | |
| FA | | HA |
| | | |
+---------+ +---------+
|
| Visited Access Home Network
| Provider Network -Private Network
Mobile | -Home Provider
IP | -Home ISP
|
+--------+
| Mobile |
| Node |
+--------+
Fig. 3 -- General Wireless IP Architecture for Mobile-IP AAA
図3-モバイルIP AAAの一般的なワイヤレスIPアーキテクチャ
In this example, a Mobile Node appears within a foreign network and issues a registration to the Foreign Agent. Since the Foreign Agent does not share any security association with the Home Agent, it sends a AAA request to its local AAA server, which includes the authentication information and the Mobile-IP registration request. The Mobile Node cannot communicate directly with the home AAA Server for two reasons:
この例では、モバイルノードが外国ネットワーク内に表示され、外国人エージェントへの登録を発行します。外国人エージェントはホームエージェントとセキュリティ協会を共有していないため、認証情報とモバイルIP登録リクエストを含むローカルAAAサーバーにAAAリクエストを送信します。モバイルノードは、2つの理由でHome AAAサーバーと直接通信することはできません。
- It does not have access to the network. The registration request is sent by the Mobile Node to request access to the network. - The Mobile Node may not have an IP address, and may be requesting that one be assigned to it by its home provider.
- ネットワークにアクセスできません。登録要求は、ネットワークへのアクセスを要求するためにモバイルノードによって送信されます。 - モバイルノードにはIPアドレスがない場合があり、ホームプロバイダーからそれを割り当てることを要求している場合があります。
The Foreign AAA Server will determine whether the request can be satisfied locally through the use of the Network Access Identifier [7] provided by the Mobile Node. The NAI has the format of user@realm and the AAA Server uses the realm portion of the NAI to identify the Mobile Node's home AAA Server. If the Foreign AAA Server does not share any security association with the Mobile Node's home AAA Server, it may forward the request to its broker. If the broker has a relationship with the home network, it can forward the request, otherwise a failed response is sent back to the Foreign AAA Server.
外国のAAAサーバーは、モバイルノードによって提供されるネットワークアクセス識別子[7]を使用して、要求をローカルで満たすことができるかどうかを判断します。NAIにはuser@realmの形式があり、AAAサーバーはNAIのレルム部分を使用してモバイルノードのホームAAAサーバーを識別します。外国のAAAサーバーがモバイルノードのホームAAAサーバーとセキュリティ協会を共有していない場合、その要求をブローカーに転送する場合があります。ブローカーがホームネットワークと関係がある場合、リクエストを転送できます。そうしないと、失敗した応答が外国のAAAサーバーに送り返されます。
When the home AAA Server receives the AAA Request, it authenticates the user and begins the authorization phase. The authorization phase includes the generation of:
Home AAAサーバーがAAAリクエストを受信すると、ユーザーを認証し、承認フェーズを開始します。承認フェーズには、次の生成が含まれます。
- Dynamic Session Keys to be distributed among all Mobility Agents - Optional Dynamic assignment of a Home Agent - Optional Dynamic assignment of a Home Address (note this could be done by the Home Agent). - Optional Assignment of QOS parameters for the Mobile Node [12]
- すべてのモビリティエージェントに配布される動的セッションキー - ホームエージェントのオプションの動的割り当て - ホームアドレスのオプションの動的割り当て（これはホームエージェントが実行できることに注意してください）。 - モバイルノードのQoSパラメーターのオプションの割り当て[12]
Once authorization is complete, the home AAA Server issues an unsolicited AAA request to the Home Agent, which includes the information in the original AAA request as well as the authorization information generated by the home AAA server. The Home Agent retrieves the Registration Request from the AAA request and processes it, then generates a Registration Reply that is sent back to the home AAA server in a AAA response. The message is forwarded through the broker back to the Foreign AAA server, and finally to the Foreign Agent.
認可が完了すると、Home AAAサーバーは、元のAAA要求の情報と、Home AAAサーバーによって生成された承認情報を含むホームエージェントに未承諾AAAリクエストを発行します。ホームエージェントは、AAAリクエストから登録要求を取得して処理し、AAA応答でホームAAAサーバーに送信される登録返信を生成します。このメッセージは、ブローカーを介して外国のAAAサーバーに戻り、最後に外国人エージェントに転送されます。
The AAA servers maintain session state information based on the authorization information. If a Mobile Node moves to another Foreign Agent within the foreign domain, a request to the foreign AAA server can immediately be done in order to immediately return the keys that were issued to the previous Foreign Agent. This minimizes an additional round trip through the internet when micro mobility is involved, and enables smooth hand-off.
AAAサーバーは、承認情報に基づいてセッション状態情報を維持します。モバイルノードが外国ドメイン内の別の外国人エージェントに移動する場合、外国のAAAサーバーへのリクエストをすぐに実行することができます。これにより、マイクロモビリティが関係するときにインターネットを介した追加の往復が最小限に抑えられ、スムーズなハンドオフが可能になります。
Mobile-IP uses the roaming pull model described in [2]. The Mobile Node is the User. The Foreign Network is the Service Provider with the Foreign Agent as the Service Equipment. The Home Network is the User Home Organization. Note that the User Home Organization operates not only a AAA Server, but also the Home Agent. Note, also, that a broker has been inserted between the Service Provider and the User Home Organization.
Mobile-IPは、[2]で説明されているローミングプルモデルを使用します。モバイルノードはユーザーです。外国ネットワークは、サービス機器として外国人エージェントを備えたサービスプロバイダーです。ホームネットワークはユーザーホーム組織です。ユーザーホーム組織は、AAAサーバーだけでなく、ホームエージェントも運営していることに注意してください。また、サービスプロバイダーとユーザーホーム組織の間にブローカーが挿入されていることにも注意してください。
Although it would have been possible for the AAA interactions to be performed for basic authentication and authorization, and the Registration flow to be sent directly to the Home Agent from the Foreign Agent, one of the key Mobile-IP AAA requirements is to minimize Internet Traversals. Including the Registration Request and Replies in the AAA messages allows for a single traversal to authenticate the user, perform authorization and process the Registration Request. This streamlined approach is required in order to minimize the latency involved in getting wireless (cellular) devices access to the network. New registrations should not increase the connect time more than what the current cellular networks provide.
基本的な認証と承認のためにAAAインタラクションを実行することは可能でしたが、登録フローは外国人エージェントからホームエージェントに直接送信される可能性がありますが、重要なモバイル-IP AAA要件の1つはインターネットトラバーサルを最小限に抑えることです。。AAAメッセージに登録要求と返信を含めることで、単一のトラバーサルを使用してユーザーを認証し、承認を実行し、登録リクエストを処理できます。この合理化されたアプローチは、ワイヤレス（セルラー）デバイスをネットワークにアクセスできるようにするのに伴うレイテンシを最小限に抑えるために必要です。新しい登録は、現在のセルラーネットワークが提供するものよりも接続時間を増やすべきではありません。
In order to allow the scaling of wireless data access across administrative domains, it is necessary to minimize the security associations required. This means that each Foreign Agent does not share a security association with each Home Agent on the Internet. The Mobility Agents share a security association with their local AAA server, which in turn shares a security association with other AAA servers. Again, the use of brokers, as defined by the Roaming Operations (roamops) Working Group, allows such services to scale by allowing the number of relationships established by the providers to be reduced.
管理ドメイン全体でワイヤレスデータアクセスをスケーリングできるようにするには、必要なセキュリティ関連を最小限に抑える必要があります。これは、各外国人エージェントがインターネット上の各ホームエージェントとセキュリティ協会を共有しないことを意味します。モビリティエージェントは、ローカルAAAサーバーとセキュリティ協会を共有し、他のAAAサーバーとセキュリティ協会を共有しています。繰り返しますが、ローミングオペレーション（ROAMOPS）のワーキンググループで定義されているブローカーの使用により、プロバイダーが確立した関係の数を減らすことにより、そのようなサービスが拡大することができます。
After a Mobile Node is authenticated, the authorization phase includes the generation of Sessions Keys. Specifically, three keys are generated:
モバイルノードが認証された後、承認フェーズにはセッションキーの生成が含まれます。具体的には、3つのキーが生成されます。
- k1 - Key to be shared between the Mobile Node and the Home Agent - k2 - Key to be shared between the Mobile Node and the Foreign Agent - k3 - Key to be shared between the Foreign Agent and the Home Agent
- K1-モバイルノードとホームエージェント間で共有されるキー-K2-モバイルノードと外国人エージェント間で共有するキー-K3-外国人エージェントとホームエージェントの間で共有されるキー
Each Key is propagated to each mobility device through the AAA protocol (for the Foreign and Home Agent) and via Mobile-IP for the Mobile Node (since the Mobile Node does not interface directly with the AAA servers).
各キーは、AAAプロトコル（外部およびホームエージェント用）およびモバイルノード用のモバイルIP経由で各モビリティデバイスに伝播されます（モバイルノードはAAAサーバーと直接インターフェイスしないため）。
Figure 4 depicts the new security associations used for Mobile-IP message integrity using the keys derived by the AAA server.
図4は、AAAサーバーによって導出されたキーを使用して、モバイルIPメッセージの整合性に使用される新しいセキュリティ協会を示しています。
+--------+ +--------+
| | k3 | |
| FA |======================| HA |
| | | |
+--------+ +--------+
\\ //
\\ k2 k1 //
\\ +--------+ //
\\ | | //
\=====| MN |=====/
| |
+--------+
Fig. 4 -- Security Association after Key Distribution
図4-キーディストリビューション後のセキュリティ協会
Once the session keys have been established and propagated, the mobility devices can exchange registration information directly without the need of the AAA infrastructure. However the session keys have a lifetime, after which the AAA infrastructure must be used in order to acquire new session keys.
セッションキーが確立され、伝播されると、モビリティデバイスはAAAインフラストラクチャを必要とせずに登録情報を直接交換できます。ただし、セッションキーには生涯があり、その後、新しいセッションキーを取得するためにAAAインフラストラクチャを使用する必要があります。
To summarize, Mobile-IP has the following authorization requirements:
要約すると、Mobile-IPには次の承認要件があります。
1. Mobile-IP requires an AAA protocol that makes use of the pull model.
1. Mobile-IPには、プルモデルを使用するAAAプロトコルが必要です。
2. Mobile-IP requires broker support, and data objects must contain data integrity and confidentiality end-to-end. This means that neither the broker nor any other intermediate AAA node should be able to decrypt the data objects, but they must be able to verify the objects' validity.
2. Mobile-IPにはブローカーのサポートが必要であり、データオブジェクトにはデータの整合性とエンドツーエンドの機密性を含める必要があります。これは、ブローカーも他の中間AAAノードもデータオブジェクトを復号化できるはずであるが、オブジェクトの有効性を確認できる必要があることを意味します。
3. Authorization includes Resource Management. This allows the AAA servers to maintain a snapshot of a mobile node's current location, keying information, etc.
3. 許可には、リソース管理が含まれます。これにより、AAAサーバーは、モバイルノードの現在の場所、キーイング情報などのスナップショットを維持できます。
4. Due to the nature of the service being offered, it is imperative that the AAA transaction add minimal latency to the connect time. Ideally, the AAA protocol should allow for a single round trip for authentication and authorization.
4. 提供されているサービスの性質上、AAAトランザクションが接続時間に最小限のレイテンシを追加することが不可欠です。理想的には、AAAプロトコルは、認証と承認のために1回の往復を可能にする必要があります。
5. If the AAA protocol allows for the Mobile-IP registration messages to be embedded within the authentication/authorization request, this will further reduce the number of round trips required and hence reduce the connect time.
5. AAAプロトコルがモバイルIP登録メッセージを認証/承認リクエスト内に埋め込むことを許可する場合、これにより、必要な往復数がさらに減少し、接続時間が短縮されます。
6. It must be possible to pass Mobile-IP specific key management data along with the authorization data. This allows the AAA server to act as a Key Distribution Center (KDC).
6. Mobile-IP固有のキー管理データと認証データを渡すことが可能である必要があります。これにより、AAAサーバーはキー配布センター（KDC）として機能することができます。
7. It must be possible to pass other application-specific data units such as home agent selection and home address assignment to be carried along with the authorization data units.
7. 認証データユニットとともに持ち運ばれるホームエージェントの選択やホームアドレスの割り当てなど、他のアプリケーション固有のデータユニットを渡すことができなければなりません。
8. The authorization response should allow for diffserv (QOS) profiles, which can be used by the mobility agents to provide some quality of service to the mobile node.
8. 承認応答では、モビリティエージェントがモバイルノードに何らかの品質を提供するために使用できるDiffServ（QOS）プロファイルを可能にする必要があります。
9. The AAA protocol must allow for unsolicited messages to be sent to a "client", such as the AAA client running on the Home Agent.
9. AAAプロトコルは、ホームエージェントで実行されているAAAクライアントなど、「クライアント」に未承諾メッセージを送信することを許可する必要があります。
This section describes authorization aspects derived from the Bandwidth Broker architecture as discussed within the Internet2 Qbone BB Advisory Council. We use authorization model concepts to identify contract relationships and trust relationships, and we present possible message exchanges. We will derive a set of authorization requirements for Bandwidth Brokers from our architectural model. The Internet 2 Qbone BB Advisory Council researches a single and multi-domain implementation based on 2-tier authorization concepts. A 3- tier model is considered as a future work item and therefore not part of this description. Information concerning the Internet 2 Bandwidth Broker work and its concepts can be found at:
このセクションでは、Internet2 QBONE BB Advisory Council内で議論されているように、帯域幅のブローカーアーキテクチャから派生した承認の側面について説明します。承認モデルの概念を使用して、契約関係を特定し、信頼関係を信頼し、可能なメッセージ交換を提示します。建築モデルから帯域幅ブローカーの一連の承認要件を導き出します。インターネット2 QBONE BB Advisory Councilは、2層認証の概念に基づいた単一およびマルチドメインの実装を調査しています。3層モデルは将来の作業項目と見なされるため、この説明の一部ではありません。インターネットに関する情報2帯域幅のブローカー作業とその概念は、次のことを見つけることができます。
http://www.merit.edu/working.groups/i2-qbone-bb
http://www.merit.edu/working.groups/i2-qbone-bb
The material in this section is based on [13] which is a work in progress of the Internet2 Qbone BB Advisory Council.
このセクションの資料は[13]に基づいており、インターネット2 QBONE BB Advisory Councilの進行中の作業です。
The establishment of a model involves four steps:
モデルの確立には4つのステップが含まれます。
1. identification of the components that are involved and what they are called in this specific environment, 2. identification of the relationships between the involved parties that are based on some form of agreement, 3. identification of the relationships that are based on trust, and 4. consideration of the sequence of messages exchanged between components.
1. 関与しているコンポーネントの識別と、この特定の環境でそれらが呼ばれるもの、2。何らかの形の合意に基づいている関係者間の関係の特定、3。信頼に基づいた関係の識別4および4。コンポーネント間で交換されるメッセージのシーケンスの考慮。
We will consider the components of a bandwidth broker transaction in the context of the conceptual entities defined in [2]. The bandwidth broker two-tier model recognizes a User and the Service Provider controlling the Service Equipment.
[2]で定義されている概念エンティティのコンテキストで、帯域幅ブローカートランザクションのコンポーネントを検討します。帯域幅ブローカーの2層モデルは、ユーザーとサービス機器を制御するサービスプロバイダーを認識します。
The components are as follows:
コンポーネントは次のとおりです。
- The Service User (User) -- A person or process willing to use certain level of QoS by requesting the allocation of a quantifiable amount of resource between a selected destination and itself. In bandwidth broker terms, the User is called a Service User, capable of generating a Resource Allocation Request (RAR).
- サービスユーザー（ユーザー） - 選択した宛先とそれ自体の間に定量化可能な量のリソースの割り当てを要求することにより、特定のレベルのQoSを使用する意思のある個人またはプロセス。帯域幅のブローカーの用語では、ユーザーはサービスユーザーと呼ばれ、リソース割り当て要求（RAR）を生成できます。
- The Bandwidth Broker (Service Provider) -- a function that authorizes allocation of a specified amount of bandwidth resource between an identified source and destination based on a set of policies. In this context we refer to this function as the Bandwidth Broker. A Bandwidth Broker is capable of managing the resource availability within a network domain it controls.
- 帯域幅ブローカー（サービスプロバイダー） - 一連のポリシーに基づいて、特定されたソースと宛先間に指定された量の帯域幅リソースの割り当てを承認する関数。この文脈では、この機能を帯域幅ブローカーと呼びます。帯域幅のブローカーは、制御するネットワークドメイン内のリソースの可用性を管理することができます。
Note: a 3-tier model involving a User Home Organization is recognized in [13], however its development is left for future study and therefore it is not discussed in this document.
注：ユーザーホーム組織を含む3層モデルは[13]で認識されていますが、その開発は将来の研究のために残されているため、このドキュメントでは議論されていません。
Authorizations to obtain bandwidth are based on contractual relationships. In both the single and multi-domain cases, the current Bandwidth Broker model assumes that a User always has a contractual relationship with the service domain to which it is connected.
帯域幅を取得するための承認は、契約上の関係に基づいています。単一およびマルチドメインの両方のケースで、現在の帯域幅ブローカーモデルは、ユーザーが常に接続されているサービスドメインと契約上の関係を持っていると想定しています。
In the single-domain case, the User has a contract with a single Service Provider in a single service domain.
単一ドメインの場合、ユーザーは単一のサービスドメインに単一のサービスプロバイダーと契約を結んでいます。
+-------------+
| |
| +---------+ |
| |Bandwidth| |
+-------+ | |Broker | |
| | | | | |
|Service| | +---------+ |
|User |=========| |
| | | +---------+ |
| | | | Network | |
+-------+ | | Routing | |
| | Devices | |
| +---------+ |
| Autonomous |
| Service |
| Domain |
+-------------+
==== contractual
relationship
Fig. 5 -- Two-Tier Single Domain Contractual Relationships
図5-二層単一ドメイン契約関係
In the multi-domain case, the User has a contract with a single Service Provider. This Service Provider has a contract with neighboring Service Providers. This model is used when independent autonomous networks establish contracts with each other.
マルチドメインの場合、ユーザーは単一のサービスプロバイダーと契約を結んでいます。このサービスプロバイダーは、近隣のサービスプロバイダーと契約を結んでいます。このモデルは、独立した自律ネットワークが互いに契約を確立するときに使用されます。
+-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |Bandwidth| | | |Bandwidth| |
+-------+ | |Broker | | | |Broker | |
| | | | | | | | | |
|Service| | +---------+ | | +---------+ |
|User |=========| |========| |
| | | +---------+ | | +---------+ |
| | | | Network | | | | Network | |
+-------+ | | Routing | | | | Routing | |
| | Devices | | | | Devices | |
| +---------+ | | +---------+ |
| Autonomous | | Autonomous |
| Service | | Service |
| Domain A | | Domain B |
+-------------+ +-------------+
==== contractual
relationship
Fig. 6 -- Two-Tier Multi-Domain Contractual Relationships
図6-二層マルチドメイン契約関係
Contractual relationships may be independent of how trust, which is necessary to facilitate authenticated and possibly secure communication, is implemented. There are several alternatives in the Bandwidth Broker environment to create trusted relationships. Figures 7 and 8 show two alternatives that are options in the two-tier Bandwidth Broker model.
契約上の関係は、認証され、場合によっては安全なコミュニケーションを促進するために必要な信頼とは独立している可能性があります。帯域幅のブローカー環境には、信頼できる関係を作成するためのいくつかの選択肢があります。図7と8は、2層の帯域幅ブローカーモデルのオプションである2つの選択肢を示しています。
+-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |Bandwidth| | | |Bandwidth| |
+-------+ | |Broker | | | |Broker | |
| O***********O O************O | |
|Service| | +----O----+ | | +----O----+ |
|User |=========| * |========| * |
| | | +----0----+ | | +----O----+ |
| | | |Network | | | |Network | |
+-------+ | |Routing | | | |Routing | |
| |Devices | | | |Devices | |
| +---------+ | | +---------+ |
| Autonomous | | Autonomous |
| Service | | Service |
| Domain A | | Domain B |
+-------------+ +-------------+
==== contractual relationship
O**O trust relationship
Fig. 7 -- Two-Tier Multi-Domain Trust Relationships, alt 1
図7-二層マルチドメイントラスト関係、alt 1
+-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |Bandwidth| | | |Bandwidth| |
+-------+ | |Broker | | | |Broker | |
| | | | | | | | | |
|Service| | +----O----+ | | +----O----+ |
|User |=========| * |========| * |
| | | +----O----+ | | +----O----+ |
| O***********O Network O************O Network | |
+-------+ | | Routing | | | | Routing | |
| | Devices | | | | Devices | |
| +---------+ | | +---------+ |
| Autonomous | | Autonomous |
| Service | | Service |
| Domain A | | Domain B |
+-------------+ +-------------+
==== contractual relationship
O**O trust relationship
Fig. 8 -- Two-Tier Multi-Domain Trust Relationships, alt 2
図8-二層マルチドメイントラスト関係、alt 2
Although [13] does not recommend specifics regarding this question, the document recognizes the need for trust relationships. In the first model, a trust relationship, based on some form of authentication method, is created between the User and the Bandwidth Broker and among Bandwidth Brokers. In the second model, which enjoys some popularity in enterprise networks, the trust relationship may be established via the wiring closet and the knowledge of which physical router port or MAC address is connected to which user. The router-Bandwidth Broker relationship may be established physically or by some other authentication method or secure channel.
[13]はこの質問に関する詳細を推奨していませんが、文書は信頼関係の必要性を認識しています。最初のモデルでは、何らかの形の認証方法に基づいた信頼関係が、ユーザーと帯域幅のブローカーと帯域幅のブローカーの間に作成されます。エンタープライズネットワークで人気を博している2番目のモデルでは、配線クローゼットと、どの物理ルーターポートまたはMACアドレスがユーザーに接続されているかについての知識を介して、信頼関係が確立される場合があります。ルーター帯域幅ブローカーの関係は、物理的に、または他の認証方法または安全なチャネルによって確立される場合があります。
A Certificate Authority (CA) based trust relationship is shown in figure 9. In this figure, a CA signs public key certificates, which then can be used in encrypted message exchanges using public keys that are trusted by all involved. As a first step, each involved party must register with the CA so it can join a trust domain. The Router-Bandwidth Broker relationship may be established as described in the two previous figures. An interesting observation regarding this kind of model is that the bandwidth broker in domain B may route information to the user via the bandwidth broker in domain A without BB1 being able to read the information (using end-to-end security). This model creates a meshed trust relationship via a tree like CA structure.
証明書局（CA）ベースの信頼関係を図9に示します。この図では、CAは公開キー証明書に署名します。これは、関係者全員が信頼できるパブリックキーを使用して、暗号化されたメッセージ交換で使用できます。最初のステップとして、関与する各当事者は、信頼ドメインに参加できるように、CAに登録する必要があります。ルーター帯域幅ブローカーの関係は、以前の2つの図に記載されているように確立できます。この種のモデルに関する興味深い観察結果は、ドメインBの帯域幅ブローカーが、BB1が情報を読むことができるドメインAの帯域幅ブローカーを介してユーザーに情報をルーティングできることです（エンドツーエンドのセキュリティを使用）。このモデルは、CA構造のようなツリーを介してメッシュ化された信頼関係を作成します。
+-------------------+
| Certificate |
....................| Authority |
: ..| |..
: : +-------------------+ :
: : :
: : :
: ***************:*********************** :
: * +---:---------+ +---*--:------+
: * | : | | * : |
: * | +-:-------+ | | +-O--:----+ |
: * | |{C} | | | | {C} | |
+---:--O+ | |Bandwidth| | | |Bandwidth| |
| {C} O***********O Broker O************O Broker | |
|Service| | +----O----+ | | +----O----+ |
|User |=========| * |========| * |
| | | +----0----+ | | +----O----+ |
| | | |Network | | | |Network | |
+-------+ | |Routing | | | |Routing | |
| |Devices | | | |Devices | |
| +---------+ | | +---------+ |
| Autonomous | | Autonomous |
| Service | | Service |
| Domain A | | Domain B |
+-------------+ +-------------+
==== contractual relationship
O**O trust relationship
{C}. certification process
Fig. 9 -- Two-Tier Multi-Domain Trust Relationships, alt 3
図9-二層マルチドメイントラスト関係、alt 3
When describing the Bandwidth Broker communication model, it is important to recognize that trust relationships between components must ensure secure and authenticated communication between the involved components. As the Internet 2 Qbone Bandwidth Broker work does not recommend any particular trust relationship model, we make the same assumptions as [13]. In theory, the trust model and communication model can be independent, however communication efficiency will determine the most logical approach.
帯域幅のブローカー通信モデルを説明する場合、コンポーネント間の信頼関係は、関係するコンポーネント間の安全で認証された通信を確保する必要があることを認識することが重要です。インターネット2 Qbone帯域幅のブローカー作業は特定の信頼関係モデルを推奨していないため、[13]と同じ仮定を行います。理論的には、信頼モデルとコミュニケーションモデルは独立している可能性がありますが、コミュニケーション効率が最も論理的なアプローチを決定します。
The current Internet 2 Qbone Bandwidth Broker discussion describes a two-tier model, where a Bandwidth Broker accepts Resource Allocation Requests (RAR's) from users belonging to its domain or RAR's generated by upstream Bandwidth Brokers from adjacent domains. Each Bandwidth Broker will manage one service domain and subsequently provide authorization based on a policy that decides whether a request can be honored.
現在のインターネット2 QBONE BANDWIDTH BROKERディスカッションでは、帯域幅ブローカーがドメインに属するユーザーからのリソース割り当て要求（RAR）を受け入れるか、隣接するドメインから上流の帯域幅ブローカーによって生成されたRARを受け入れる2層モデルについて説明しています。各帯域幅のブローカーは、1つのサービスドメインを管理し、その後、リクエストを尊重できるかどうかを決定するポリシーに基づいて承認を提供します。
Admission Authorization or Connection Admission Control (CAC) for intra-domain communication is performed using whatever method is appropriate for determining availability of resources within the domain. Generally a Bandwidth Broker configures its service domain to certain levels of service. RAR's are subsequently accommodated using a policy-based decision.
ドメイン内通信のための入場許可または接続入学制御（CAC）は、ドメイン内のリソースの可用性を決定するのに適した方法を使用して実行されます。通常、帯域幅のブローカーは、そのサービスドメインを特定のレベルのサービスに構成します。その後、RARはポリシーベースの決定を使用して収容されます。
Service Level Specifications (SLS's) provide the basis for handling inter-domain bandwidth authorization requests. A Bandwidth Broker monitors both the state of its network components and the state of its connections to neighboring networks. SLS's are translations of SLA's established between Autonomous Service Domains. Each Bandwidth Broker will initialize itself so it is aware of existing SLS's. SLS's are established in a unidirectional sense. Two SLS's must govern a bi-directional connection. SLS's are established on the level of aggregate data-flows and the resources (bandwidth) provisioned for these flows.
サービスレベルの仕様（SLS）は、ドメイン間帯域幅の承認要求を処理するための基礎を提供します。帯域幅のブローカーは、ネットワークコンポーネントの状態と隣接ネットワークへの接続の状態の両方を監視します。SLSは、自律サービスドメイン間で確立されたSLAの翻訳です。各帯域幅のブローカーは初期化されるため、既存のSLSを認識します。SLSは単方向の意味で確立されています。2つのSLSは、双方向接続を管理する必要があります。SLSは、これらのフロー用にプロビジョニングされた集約データフローとリソース（帯域幅）のレベルで確立されています。
A Bandwidth Broker may honor an inter-domain RAR by applying policy decisions determining that a particular RAR does fit into a pre-established SLS. If successful, the Bandwidth Broker will authorize the usage of the bandwidth. If unsuccessful, the Bandwidth Broker may deny the request or approve the request after it has re-negotiated the SLS with its downstream Bandwidth Broker.
帯域幅のブローカーは、特定のRARが事前に確立されたSLSに収まると判断するポリシー決定を適用することにより、ドメイン間RARを尊重する場合があります。成功した場合、帯域幅のブローカーは帯域幅の使用を承認します。失敗した場合、帯域幅のブローカーは、SLSを下流の帯域幅ブローカーと再交渉した後、リクエストを拒否したり、リクエストを承認したりする可能性があります。
A separate Policy Manager may be involved in the CAC decision. The Internet 2 Qbone Bandwidth Broker discussion recognizes an ideal environment where Bandwidth Brokers and Policy Managers work together to provide CAC using integrated policy services [13].
別のポリシーマネージャーがCACの決定に関与している可能性があります。インターネット2 QBONE帯域幅のブローカーディスカッションは、帯域幅のブローカーとポリシーマネージャーが協力して統合ポリシーサービスを使用してCACを提供する理想的な環境を認識しています[13]。
The Internet 2 Qbone Bandwidth Broker discussion proposes development of the Bandwidth Broker model in several phases:
インターネット2 Qbone帯域幅ブローカーディスカッションでは、いくつかのフェーズで帯域幅ブローカーモデルの開発を提案しています。
- Phase 0: Local Admission. RAR's are only handled within a local domain. SLS's are pre-established using manual methods (fax, e-mail).
- フェーズ0：現地の入場。RARはローカルドメイン内でのみ処理されます。SLSは、手動方法（FAX、電子メール）を使用して事前に確立されています。
- Phase 1: Informed Admission. RAR's spanning multiple domains are authorized based on information obtained from one or more Bandwidth Brokers along the path.
- フェーズ1：情報に基づいた入場。RARの複数のドメインにまたがる複数のドメインは、パスに沿った1つ以上の帯域幅ブローカーから得られた情報に基づいて承認されています。
- Phase 2: Dynamic SLS admission. Bandwidth Brokers can dynamically set up new SLS's.
- フェーズ2：動的SLS入場。帯域幅ブローカーは、新しいSLSを動的にセットアップできます。
Although the local admission case is addressed, the current Internet 2 Qbone Bandwidth Broker work is currently concerned with solving multi-domain problems in order to allow individual Bandwidth Brokers to inter-operate as identified in phase 0 or 1.
ローカル入場事例に対処しますが、現在のインターネット2 Qbone帯域幅ブローカー作業は、フェーズ0または1で個別の帯域幅ブローカーが操作できるようにするために、マルチドメインの問題を解決することに現在関係しています。
In phase 0 implementations, no electronic signaling between Bandwidth Brokers is performed and SLS negotiation will be performed manually (phone, email etc) by network operators. An RAR is only handled within the domain and may originate from a User or ingress router.
フェーズ0の実装では、帯域幅ブローカー間の電子シグナルは実行されず、SLS交渉はネットワークオペレーターによって手動で実行されます（電話、電子メールなど）。RARはドメイン内でのみ処理され、ユーザーまたはイングレスルーターから発生する場合があります。
Here a CAC decision is made on information obtained from downstream Bandwidth Brokers. This information could come from the next hop Bandwidth Broker or all Bandwidth Brokers downstream to the destination.
ここでは、下流の帯域幅ブローカーから得られた情報についてCACの決定が下されます。この情報は、次のホップ帯域幅のブローカーまたは目的地の下流のすべての帯域幅ブローカーから来る可能性があります。
Two fundamental signaling approaches between Bandwidth Brokers have been identified for the Informed Admission case. These are illustrated in figure 10.
帯域幅ブローカー間の2つの基本的なシグナル伝達アプローチが、情報に基づいた入場事件について特定されています。これらを図10に示します。
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| |RAR | | 1 | | 2 | |
| User |-------->| |-------->| |-------->| |
| | RAA | BB1 | 4 | BB2 | 3 | BB3 |
| |<--------| |<--------| |<--------| |
| | | | | | | |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
A)End-to-end signaling
a）エンドツーエンドのシグナル伝達
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| |RAR | | 1 | | 3 | |
| User |-------->| |-------->| |-------->| |
| | RAA | BB1 | 2 | BB2 | 4 | BB3 |
| |<--------| |<--------| |<--------| |
| | 7 | | 6 | | 5 | |
| |<--------| |<--------| |<--------| |
+-------+ +-------+ +-------+ +-------+
B) Immediate response signaling.
b）即時応答シグナル伝達。
Fig. 10 -- Fundamental Signalling Approaches
図10-基本的なシグナル伝達アプローチ
- End to End signaling. An RAR from a User to BB1 is forwarded to BB2 (1). BB2 will forward the request to BB3 (2). If BB3 is the destination of the request, BB3 will authorize the request and reply to BB2 (3). BB2 will then reply to BB1 (4), and BB1 will send a Resource Allocation Answer (RAA) back to the User to complete the authorization.
- エンドツーエンドシグナリング。ユーザーからBB1へのRARは、BB2に転送されます（1）。BB2はリクエストをBB3（2）に転送します。BB3がリクエストの宛先である場合、BB3はリクエストを承認し、BB2（3）に返信します。その後、BB2はBB1（4）に返信し、BB1はリソース割り当て回答（RAA）をユーザーに送り返し、認証を完了します。
- Immediate response signaling. This is the case where BB1 will want to authorize an RAR from its domain and forwards the authorization request to BB2 (1). If BB2 approves, the response is immediately returned to BB1 (2). BB1 will send an RAA back to the User. If the authorization was positive BB2 will forward subsequently a request to the next BB, BB3 (3). BB3 authorizes the request and responds to BB2 (4). If the response is negative (5), BB2 will cancel the authorization it previously issued to BB1 (6) and this will result in a cancellation from BB1 to the user (7). In this case the RAA authorization is valid until revoked by 7.
- 即時応答シグナル伝達。これは、BB1がそのドメインからRARを承認し、承認要求をBB2（1）に転送したい場合です。BB2が承認した場合、応答はすぐにBB1に返されます（2）。BB1はRAAをユーザーに送り返します。承認が肯定的である場合、BB2が次のBBにリクエストを転送します。BB3（3）。BB3はリクエストを許可し、BB2に応答します（4）。応答が負（5）の場合、BB2は以前にBB1に発行された承認をキャンセルし（6）、これによりBB1からユーザーへのキャンセルが発生します（7）。この場合、RAA認証は7で取り消されるまで有効です。
Figure 11 shows components of the discussed Bandwidth Broker architecture with its interfaces.
図11は、議論された帯域幅のブローカーアーキテクチャのコンポーネントをそのインターフェースと示しています。
- An intra-domain interface allows communication with all the service components within the network that the Bandwidth Broker controls.
- ドメイン内インターフェイスにより、帯域幅のブローカーが制御するネットワーク内のすべてのサービスコンポーネントとの通信が可能になります。
- An inter-domain interface allows communication between Bandwidth Brokers of different autonomous networks.
- ドメイン間インターフェイスにより、さまざまな自律ネットワークの帯域幅ブローカー間の通信が可能になります。
- A user/application interface allows the Bandwidth Broker to be managed manually. Requests can be sent from the User or a host application.
- ユーザー/アプリケーションインターフェイスにより、帯域幅のブローカーを手動で管理できます。リクエストは、ユーザーまたはホストアプリケーションから送信できます。
- A policy manager interface allows implementation of complex policy management or admission control.
- ポリシーマネージャーインターフェイスにより、複雑なポリシー管理または入場管理の実装が可能になります。
- A routing table interface allows the Bandwidth Broker to understand the network topology.
- ルーティングテーブルインターフェイスにより、帯域幅のブローカーはネットワークトポロジを理解できます。
- An NMS interface allows coordination of network provisioning and monitoring.
- NMSインターフェイスにより、ネットワークのプロビジョニングと監視の調整が可能になります。
adjacent BB <---------------------------> adjacent BB
|
V
+------------------------------+
| | inter-domain | |
| -------------- ------|
application | | PM |
server \ | |iface |
\ |------- ---------+ ------|
->| user/ | | simple | ------|
user/host-->| app | | policy | | NMS |
->| iface | | services| |iface |
/ |------- ---------+ ------|
network / | |
operator | ------- ------- |
| | data | |routing| |
| | store | |info | |
| | | | | |
| ------- ------- |
| |
| ---------------- |
| | intra-domain | |
+------------------------------+
^
|
edge router(s) <---------------------------> edge router(s)
Fig. 11 -- Bandwidth Broker Architecture
図11-帯域幅ブローカーアーキテクチャ
Before Bandwidth Brokers can configure services between two adjacent domains, they have to establish and initialize a relationship. No authentication is used; therefore any trust relationship is implicit. Part of the initialization is an exchange of topology information (list of adjacent Bandwidth Brokers).
帯域幅のブローカーが2つの隣接するドメイン間でサービスを構成する前に、関係を確立して初期化する必要があります。認証は使用されていません。したがって、信頼関係は暗黙的です。初期化の一部は、トポロジー情報の交換（隣接する帯域幅ブローカーのリスト）です。
The Bandwidth Broker must first be configured in regard to agreed bi-lateral service levels. All resources allocated to a particular level of provisioned service must be reserved in each domain.
帯域幅のブローカーは、合意された二国間サービスレベルに関して最初に構成する必要があります。特定のレベルのプロビジョニングサービスに割り当てられたすべてのリソースは、各ドメインに予約する必要があります。
A Service Setup Request (SSR) is generated (on demand by the operator or at startup of the system) and forwarded to a downstream Bandwidth Broker. The downstream Bandwidth Broker will check the consistency with its own service level specifications and respond with Setup Answer message (SA) agreements. This message exchange confirms and identifies pre-established service authorization levels.
サービスセットアップリクエスト（SSR）が生成され（オペレーターまたはシステムの起動時）、下流の帯域幅ブローカーに転送されます。ダウンストリーム帯域幅のブローカーは、独自のサービスレベルの仕様との一貫性を確認し、セットアップ回答メッセージ（SA）契約で応答します。このメッセージ交換は、事前に確立されたサービス認証レベルを確認および識別します。
A Service Cancellation (SC) message may cancel a service authorization. This message may be initiated by the operator or by an expiration date. A Cancellation Answer (CA) is returned.
サービスキャンセル（SC）メッセージは、サービス承認をキャンセルする場合があります。このメッセージは、オペレーターまたは有効期限によって開始される場合があります。キャンセル回答（CA）が返されます。
An (optional) Service-Renegotiation message (SR) may allow a Bandwidth Broker to re-negotiate an existing service. This message may be initiated by the operator or automatically when a certain threshold is reached. Renegotiations happen within the margins of a pre-established authorization.
（オプションの）サービス再検索メッセージ（SR）により、帯域幅のブローカーが既存のサービスを再接続できる場合があります。このメッセージは、特定のしきい値に到達したときにオペレーターによって、または自動的に開始される場合があります。再交渉は、事前に確立された許可のマージン内で発生します。
An RAR allocates a requested level of service on behalf of the User and when available it will decide on the admittance of a certain User to the service. A Bandwidth Broker may receive an RAR via either the intra-domain or inter-domain interface. The RAR must refer to the Service SetUp Identification (SSU_ID), which binds a request to a certain authorization. A Resource Allocation Answer (RAA) confirms or rejects a request or it may indicate an "in progress" state.
RARは、ユーザーに代わって要求されたレベルのサービスを割り当て、利用可能な場合、特定のユーザーのサービスへの入場を決定します。帯域幅のブローカーは、ドメイン内またはドメイン間インターフェイスのいずれかを介してRARを受け取る場合があります。RARは、特定の承認にリクエストを拘束するサービスセットアップ識別（SSU_ID）を参照する必要があります。リソース割り当て回答（RAA）は、リクエストを確認または拒否します。または、「進行中」状態を示す場合があります。
A certain level of session maintenance is required to keep Bandwidth Brokers aware of each other. This must be implemented using time-outs and keep-alive messages. This will help Bandwidth Brokers to notice when other Bandwidth Brokers disappear.
帯域幅のブローカーを互いに認識し続けるには、一定レベルのセッションメンテナンスが必要です。これは、タイムアウトと維持対象のメッセージを使用して実装する必要があります。これは、帯域幅のブローカーが他の帯域幅ブローカーが消えるときに気付くのに役立ちます。
The Intra-domain interface protocol used between a Bandwidth Broker and the routers it controls may be COPS, SNMP, or Telnet Command Line Interface.
帯域幅のブローカーと制御するルーターの間で使用されるドメイン内インターフェイスプロトコルは、COPS、SNMP、またはTelnetコマンドラインインターフェイスです。
From the above descriptions we derive the following requirements.
上記の説明から、次の要件を導き出します。
- The Authorization mechanism may require trust relationships to be established before any requests can be made from the User to the Service Provider. Currently trust relationship establishment is implicit.
- 承認メカニズムは、ユーザーからサービスプロバイダーへのリクエストを行う前に、信頼関係を確立する必要がある場合があります。現在、信頼関係の確立は暗黙的です。
- A confirmation of authorization is required in order to initialize the system.
- システムを初期化するには、認可の確認が必要です。
- A negation of static authorization is required to shut down certain services.
- 特定のサービスをシャットダウンするには、静的な承認の否定が必要です。
- A renegotiation of static authorization is required to alter services (SLS's).
- サービス（SLS）を変更するには、静的承認の再交渉が必要です。
- Dynamic authorization requests (RAR) must fit into pre-established static authorizations (SLS's).
- 動的承認要求（RAR）は、事前に確立された静的承認（SLS）に適合する必要があります。
- Dynamic authorization requests (RAR) may be answered by an "in progress state" answer.
- 動的認証要求（RAR）は、「進行中の状態」の回答によって回答される場合があります。
- Provisions must be made to allow reconstruction of authorization states after a Bandwidth Broker re-initializes.
- 帯域幅のブローカーが再目的化された後、承認状態の再構築を許可するための規定を作成する必要があります。
The Internet Printing Protocol, IPP [14], has some potentially complex authorization requirements, in particular with the "print-by-reference" model. The following attempts to describe some possible ways in which an authorization solution for this aspect of IPP might work, and to relate these to the framework described in [2]. This is not a product of the IPP working group, and is meant only to illustrate some issues in authorization in order to establish requirements for a "generic" protocol to support AAA functions across many applications.
インターネット印刷プロトコルであるIPP [14]には、特に「印刷ごと」モデルを備えた複雑な承認要件がいくつかあります。IPPのこの側面の承認ソリューションが機能し、これらを[2]で説明したフレームワークに関連付ける可能性のあるいくつかの可能な方法を説明する以下の試み。これはIPPワーキンググループの製品ではなく、多くのアプリケーションでAAA機能をサポートする「ジェネリック」プロトコルの要件を確立するために、許可におけるいくつかの問題を説明することのみを目的としています。
IPP print-by-reference allows a user to request a print service to print a particular file. The user creates a request to print a particular file on a printer (or one of a group of printers). The key aspect is that the request includes only the file name and not the file content. The print service must then read the file from a file server prior to printing. Both the file server and the print server must authorize the request. Once initiated, printing will be done without intervention of the user; i.e., the file will be sent directly to the print service rather than through the user to the printer.
IPP Print-by-Referenceを使用すると、ユーザーは特定のファイルを印刷するように印刷サービスを要求できます。ユーザーは、プリンター（またはプリンターのグループの1つ）に特定のファイルを印刷するリクエストを作成します。重要な側面は、リクエストにはファイル名のみが含まれ、ファイルコンテンツではないことです。印刷サービスは、印刷前にファイルサーバーからファイルを読み取る必要があります。ファイルサーバーと印刷サーバーの両方がリクエストを承認する必要があります。開始すると、ユーザーの介入なしに印刷が行われます。つまり、ファイルはユーザーを介してプリンターまでではなく、印刷サービスに直接送信されます。
The assumption is that the Printer and File Server may be owned and operated by different organizations. There appear to be two models for how "agreements" can be set up.
仮定は、プリンターとファイルサーバーがさまざまな組織が所有および運用できることです。「合意」をどのように設定できるかについては、2つのモデルがあるようです。
1. User has agreement with Print Server; Print Server has agreement with File Server.
1. ユーザーは印刷サーバーと合意しています。印刷サーバーは、ファイルサーバーと一致しています。
2. User has agreements with both File and Print Server directly.
2. ユーザーは、ファイルと印刷サーバーの両方と直接契約しています。
In case 1, the user has a trust relationship with the Print Service AAA Server. The Printer forwards the request to the File Server. The File Server authorizes the Printer and determines if the Printer is allowed access to the file. Note that while there may be some cases where a Print Server may on its own be allowed access to files (perhaps some "public files", or that can only be printed on certain "secure" printers), it is normally the case that files are associated with users and not with printers. This is not a good "generic" model as it tends to make the print service an attractive point of attack.
ケース1では、ユーザーは印刷サービスAAAサーバーと信頼関係を持っています。プリンターはリクエストをファイルサーバーに転送します。ファイルサーバーはプリンターを承認し、プリンターがファイルへのアクセスを許可されているかどうかを判断します。印刷サーバーがファイルへのアクセスを許可される場合（おそらく「パブリックファイル」、または特定の「セキュア」プリンターでのみ印刷できる場合）には、通常、ファイルがファイルである場合があることに注意してください。プリンターではなくユーザーに関連付けられています。これは、印刷サービスを魅力的な攻撃ポイントにする傾向があるため、優れた「ジェネリック」モデルではありません。
+------+ +----------------------+
| | | File Service |----+
| | | AAA Server |<-+ |
| | +----------------------+ | |
| | | | | |
| | | File Server | | |
| | | | | |
| User | +----------------------+ | |
| | | |
| | | |
| | | |
| | +----------------------+ | |
| |------>| Print Service |--+ |
| |<------| AAA Server |<---+
| | +----------------------+
| | | Print Server |
| | | and Printer |
+------+ +----------------------+
Fig. 12 -- Case 1 User authorizes with Print Service. Printer authorizes with File Service.
図12-ケース1ユーザーは印刷サービスで承認します。プリンターはファイルサービスで承認します。
In case 2, the user must have a trust relationship with both the file and print services so that each can verify the service appropriate to the User. In this case, the User first contacts the File Service AAA Server and requests that it enable authorization for the Print Service to access the file. This might be done in various ways, for example the File Service AAA Server may return a token to the User which can (via the Print Service) be presented to the File Server to enable access.
ケース2では、ユーザーがファイルサービスと印刷サービスの両方と信頼関係を持つ必要があり、それぞれがユーザーに適したサービスを確認できるようにする必要があります。この場合、ユーザーは最初にファイルサービスAAAサーバーに連絡し、印刷サービスがファイルにアクセスする許可を有効にすることを要求します。これはさまざまな方法で行われる場合があります。たとえば、ファイルサービスAAAサーバーは、（印刷サービスを介して）ファイルサーバーに提示してアクセスを有効にする可能性のあるユーザーにトークンを返す場合があります。
+------+ +----------------------+
| |------>| File Service |
| |<------| AAA Server |
| | +----------------------+
| |
| | +----------------------+
| | | File Server |
| User | +----------------------+
| | /|\ |
| | | |
| | | \|/
| | +----------------------+
| |------>| Print Service |
| |<------| AAA Server |
| | +----------------------+
| | | Print Server |
| | | and Printer |
+------+ +----------------------+
Fig. 13 -- Case 2 User authorizes File and Print Service. Must create binding for session between Print Service and File Service.
図13-ケース2ユーザーはファイルと印刷サービスを承認します。印刷サービスとファイルサービスの間のセッションのバインディングを作成する必要があります。
The print-by-reference case provides a good example of the use of attribute certificates as discussed in [2]. If we describe case 2 above in terms of attribute certificates (ACs) we get the diagram shown in figure 14.
リファレンスごとのケースは、[2]で説明されているように、属性証明書の使用の良い例を提供します。属性証明書（ACS）の観点から上記のケース2を説明する場合、図14に示す図を取得します。
+------+ +----------------------+
| |------>| File Service |
| |<------| AAA Server |
| |Get AC +----------------------+
| |
| | +----------------------+
| | | File Server |----+
| | | |<-+ |
| User | +----------------------+ | |
| | | |
| | +---authorize passing AC | |<---Create session
| | | | | Using AC
| | V +----------------------+ | |
| |------>| Print Service | | |
| |<------| AAA Server | | |
| | +----------------------+ | |
| | | Print Server |--+ |
| | | and Printer |<---+
+------+ +----------------------+
Fig. 14 -- Using Attribute Certificates in IPP Authorization
図14-IPP認証で属性証明書を使用する
In this case, the User gets an AC from the File Service's AAA Server which is signed by the File Service AAA Server and contains a set of attributes describing what the holder of the AC is allowed to do. The User then authorizes with the Print Service AAA Server and passes the AC in the authorization request. The Printer establishes a session with the File Server, passing it the AC. The File Server trusts the AC because it is signed by the File Service AAA Server and allows (or disallows) the session.
この場合、ユーザーはファイルサービスAAAサーバーによって署名されたファイルサービスのAAAサーバーからACを取得し、ACの所有者が許可されていることを説明する属性のセットを含みます。その後、ユーザーは印刷サービスAAAサーバーで承認し、承認リクエストでACを渡します。プリンターは、ファイルサーバーとのセッションを確立し、ACを渡します。ファイルサーバーは、ファイルサービスAAAサーバーによって署名されており、セッションを許可する（または許可する）ため、ACを信頼します。
It is interesting to note that an AC could also be created and signed by the User, and passed from the Print Server to the File Server. The File Server would need to be able to recognize the User's signature. Yet another possibility is that the Print Service AAA Server could simply authenticate the User and then request an AC from the File Service AAA Server.
また、ACをユーザーが作成および署名し、印刷サーバーからファイルサーバーに渡すことができることに注意するのは興味深いことです。ファイルサーバーは、ユーザーの署名を認識できる必要があります。さらに別の可能性は、印刷サービスAAAサーバーがユーザーを認証し、ファイルサービスAAAサーバーからACを要求できることです。
The descriptive model presented in [2] includes four basic elements: User, User Home Organization, Service Provider AAA Server, and Service Equipment.
[2]に示されている記述モデルには、ユーザー、ユーザーホーム組織、サービスプロバイダーAAAサーバー、およびサービス機器の4つの基本要素が含まれています。
Mapping these to IPP, the User is the same, the User Home Organization (if included) is the same. The Service Provider AAA Server and the Service Equipment are expected to be closely coupled on the same processor. In other words, the interface between the Print Service AAA Server and the Printer as well as that between the File Service AAA Server and the File Server is an internal one that will not require a formal protocol (although some standard API might be useful).
これらをIPPにマッピングすると、ユーザーは同じです。ユーザーホーム組織（含まれる場合）は同じです。サービスプロバイダーAAAサーバーとサービス機器は、同じプロセッサに密接に結合されると予想されます。言い換えれば、印刷サービスAAAサーバーとプリンターとの間のインターフェイスと、ファイルサービスAAAサーバーとファイルサーバー間のインターフェイスは、正式なプロトコルを必要としない内部のインターフェースです（ただし、一部の標準APIが役立つ場合があります）。
The concept of a Resource Manager (see [2]) has some interesting twists relative to IPP. Once started, the user is not involved in the service, but until printing is complete it seems useful that any of the parties in the authorization process be allowed to query for status or to cancel the print session. The user needs a way to "bind" to a particular session, and may have to reauthorize to be allowed to access Resource Manager information.
リソースマネージャーの概念（[2]を参照）には、IPPに比べて興味深いねじれがあります。開始すると、ユーザーはサービスに関与しませんが、印刷が完了するまで、承認プロセスの当事者のいずれかがステータスを照会するか、印刷セッションをキャンセルすることを許可することが有用であると思われます。ユーザーは、特定のセッションに「バインド」する方法が必要であり、リソースマネージャーの情報にアクセスできるように再承認する必要がある場合があります。
This section describes the authorization aspects of an e-commerce architecture typically used in Europe. We will use this model to identify contractual and trust relationships and message exchanges. We will then identify a set of authorization requirements for e-commerce.
このセクションでは、ヨーロッパで通常使用されるeコマースアーキテクチャの承認の側面について説明します。このモデルを使用して、契約上および信頼関係とメッセージ交換を特定します。次に、eコマースの一連の承認要件を特定します。
Whereas most e-commerce protocols focus on authentication and message integrity, e-commerce exchanges as described by the Internet Open Trading Protocol (trade) Working Group in [15] also involve authorization. This section will examine one e-commerce protocol called SET (Secure Electronic Transaction) that provides for credit and debit card payments. We will analyze the authorization aspects from an architectural viewpoint. We will apply concepts and terms defined in [2].
ほとんどのeコマースプロトコルは認証とメッセージの整合性に焦点を当てていますが、[15]のインターネットオープントレーディングプロトコル（Trade）ワーキンググループで説明されているeコマース交換も承認を伴います。このセクションでは、クレジットカードの支払いとデビットカードの支払いを提供するSet（Secure Electronic Transaction）と呼ばれる1つのeコマースプロトコルを検討します。アーキテクチャの視点からの承認の側面を分析します。[2]で定義されている概念と用語を適用します。
We are not here proposing SET as a standard authorization protocol. Rather, we are examining the SET model as a way of understanding the e-commerce problem domain so that we can derive requirements that an authorization protocol would have to meet in order to be used in that domain.
ここでは、標準的な承認プロトコルとしてセットを提案していません。むしろ、eコマースの問題ドメインを理解する方法として設定モデルを検討しているため、そのドメインで使用するために認可プロトコルが満たさなければならない要件を導き出すことができます。
E-commerce protocols and mechanisms such as those described in [16] may not only be important to allow customers to shop safely in Cyberspace, but may also be important for purchases of Internet services as well. With emerging technologies allowing Internet transport services to be differentiated, an inherently more complex pricing model will be required as well as additional payment methods. Flexible authorization of services will be an important aspect to allow, for example, globally roaming users ad hoc allocation of premium bandwidth with an ISP who is authorized to accept certain credit card brands.
[16]に記載されているような電子商取引プロトコルとメカニズムは、顧客がサイバースペースで安全に買い物をすることを許可するために重要であるだけでなく、インターネットサービスの購入にも重要かもしれません。インターネット輸送サービスを区別できるようにする新しいテクノロジーでは、本質的に複雑な価格設定モデルと追加の支払い方法が必要になります。サービスの柔軟な承認は、たとえば、特定のクレジットカードブランドを受け入れる権限を与えられたISPとのプレミアム帯域幅のアドホックな割り当てをグローバルにローミングすることを許可する重要な側面になります。
The establishment of a model involves four steps:
モデルの確立には4つのステップが含まれます。
1. identification of the components that are involved and what they are called in this specific environment, 2. identification of the relationships between the involved parties that are based on some form of agreement, 3. identification of the relationships that are based on trust, and 4. consideration of the sequence of messages exchanged between components.
1. 関与しているコンポーネントの識別と、この特定の環境でそれらが呼ばれるもの、2。何らかの形の合意に基づいている関係者間の関係の特定、3。信頼に基づいた関係の識別4および4。コンポーネント間で交換されるメッセージのシーケンスの考慮。
We will consider the components of an electronic commerce transaction in the context of the conceptual entities defined in [2].
[2]で定義されている概念エンティティのコンテキストで、電子商取引トランザクションのコンポーネントを検討します。
- The Cardholder (User) -- the person or organization that is to receive and pay for the goods or services after a request to purchase has been received. In SET terms this is called a Cardholder.
- カード所有者（ユーザー） - 購入のリクエストを受け取った後に商品またはサービスを受け取って支払う人または組織。設定されていることでは、これはカード所有者と呼ばれます。
- The Issuer (User Home Organization) -- the financial organization that guarantees to pay for authorized transactions to purchase goods or services on behalf of the User when using a debit or credit card it issues. The financial organization (typically a bank or Brand Organization) will transfer money from the user account to the account the party to which the User instructs it to send the payment. The issued card authorizes the User to use the card for payments to merchants who are authorized to accept the card. In SET terms this organization is called the Issuer. This organization is considered "home" to the Cardholder.
- 発行者（ユーザーホーム組織） - デビットカードまたはクレジットカードを使用する際に、ユーザーに代わって商品またはサービスを購入するための許可された取引の支払いを保証する金融組織。金融組織（通常、銀行またはブランド組織）は、ユーザーアカウントからアカウントにお金を譲渡します。ユーザーが支払いを送信するよう指示します。発行されたカードは、ユーザーがカードを受け入れることを許可されている商人への支払いにカードを使用することを許可します。設定されていることでは、この組織は発行者と呼ばれます。この組織は、カード所有者にとって「ホーム」と見なされます。
- The Merchant (Service Provider) -- the organization from whom the purchase is being made and who is legally responsible for providing the goods or services and receives the benefit of the payment made. In SET terms this organization is called a Merchant. The Cardholder is considered to be "foreign" to the Merchant.
- 商人（サービスプロバイダー） - 購入が行われている組織と、商品またはサービスの提供に法的責任を負い、支払いの利益を受け取る組織。設定されていることでは、この組織は商人と呼ばれます。カード所有者は、商人にとって「外国人」と見なされます。
- The Acquirer (Broker) -- the organization that processes credit or debit card transactions. Although in reality this function may be rather complex and may span several organizations, we will simply assume this organization to be a Brand Organization fulfilling the role of the Acquirer as defined in SET. The Acquirer establishes an account with the Merchant. The Acquirer operates a Payment Gateway that will accept payment authorization requests from authorized merchants and provide responses from the issuer. The Acquirer will forward an authorization request to the Issuer. The Acquirer is considered "home" to the Merchant.
- 取得者（ブローカー） - クレジットカードトランザクションまたはデビットカードトランザクションを処理する組織。実際には、この機能はかなり複雑であり、いくつかの組織にまたがっている可能性がありますが、この組織は、セットで定義されている取得者の役割を果たしているブランド組織であると単純に想定します。取得者は、商人とのアカウントを確立します。取得者は、認定商人からの支払い承認要求を受け入れ、発行者からの回答を提供する支払いゲートウェイを運用します。取得者は、承認要求を発行者に転送します。買収者は、商人にとって「家」と見なされます。
As the SET document [16] notes, a Brand Organization (credit card organization) may handle both the Issuer function and Acquirer function that operates a Payment Gateway. For simplicity, we therefore assume that the authorization role of Broker (Acquirer) and User Home Organization (Issuer) both belong to the Brand Organization.
セットドキュメント[16]が注目しているように、ブランド組織（クレジットカード組織）は、支払いゲートウェイを操作する発行者機能と取得者機能の両方を処理する場合があります。したがって、簡単にするために、ブローカー（取得者）とユーザーホーム組織（発行者）の承認の役割は、どちらもブランド組織に属していると想定しています。
In order to be more descriptive we now use the SET terms. In the requirements section these terms are mapped back into the authorization framework terms again.
より説明的になるためには、設定された用語を使用します。要件セクションでは、これらの用語は、再び承認フレームワークの用語にマッピングされます。
Contractual relationships are illustrated in figure 15, below.
契約上の関係を以下の図15に示します。
- The Cardholder has a contractual relationship with the card Issuer. The Cardholder holds an account with the Issuer and obtains an account number.
- カード所有者は、カード発行者と契約上の関係を持っています。カード所有者は発行者とともにアカウントを保持し、アカウント番号を取得します。
- The Merchant has a contractual relationship with the Acquirer. The Merchant obtains a Merchant ID from the Acquirer.
- 商人は、買収者と契約上の関係を持っています。販売者は、取得者から商人IDを取得します。
- In the real world there may be no direct contractual relationship between the Issuer and the Acquirer. The contractual relationships allowing an Acquirer to relay a payment authorization request to an Issuer may be very complex and distributed over multiple organizations. For simplicity, however, we assume there are contracts in place allowing an Acquirer to request payment authorization from an Issuer. These contracts are facilitated by the Brand Organization. Therefore, in our simplified example, the Acquirer and Issuer belong to the same Brand Organization. The Acquirer operates a Payment Gateway for which it needs a Bank Identification Number (BIN).
- 現実の世界では、発行者と買収者の間に直接的な契約上の関係はないかもしれません。買収者が支払い承認要求を発行者に中継することを可能にする契約上の関係は、非常に複雑であり、複数の組織に分配される場合があります。ただし、簡単にするために、契約が整っており、買収者が発行者から支払い承認を要求できるようにすると想定しています。これらの契約は、ブランド組織によって促進されます。したがって、単純化された例では、取得者と発行者は同じブランド組織に属します。取得者は、銀行識別番号（BIN）が必要な支払いゲートウェイを操作します。
+----------------+ +------------------------+
| Issuer | | Acquirer |
| (User Home | | (Broker) |
| Organization) | | +------------------+ |
| |=======| | Payment | |
| | | | Gateway | |
| | | +------------------+ |
| | | |
+----------------+ +------------------------+
|| ||
|| ||
|| ||
+----------------+ +--------------------+
| Cardholder | | Merchant |
| (User) | | (Service Provider) |---+
| | | | |
| | | | |
| | +--------------------+ |
| | | |
| | | Fulfillment |
| | | |
+----------------+ +----------------------+
Fig. 15 -- SET Contractual Relationships
図15-契約関係を設定します
It is important to recognize that there are two kinds of trust relationships: static and dynamic trust relationships. Static trust relationships in SET are established by means of a registration process that will request a certificate to be issued to the party that needs to be trusted and authorized to be part of a SET transaction. Dynamic trust is created at the time of a payment transaction and its subsequent authorization request. Note that at the issue phase of a certificate, based on identification and registration, the user of the certificate gets an implicit static authorization and a means of authenticating and securing messages. For this purpose a Certificate Authority (CA) will issue certificates that are used to sign and/or encrypt messages exchanged according to the SET protocol.
静的および動的な信頼関係の2種類の信頼関係があることを認識することが重要です。SETの静的信頼関係は、セット取引の一部であると信頼され、許可される必要がある当事者に発行される証明書を要求する登録プロセスによって確立されます。Dynamic Trustは、支払い取引とその後の承認要求の時点で作成されます。証明書の問題フェーズでは、識別と登録に基づいて、証明書のユーザーは、暗黙の静的承認とメッセージを認証および保護する手段を取得することに注意してください。この目的のために、証明書局（CA）は、セットプロトコルに従って交換されたメッセージに署名および/または暗号化するために使用される証明書を発行します。
In the discussion that follows, refer to figure 16, below.
以下の議論では、以下の図16を参照してください。
+-------+
| Root |
| CA |
+-------+ CA = Certificate Authority
| {C} = Certificate
|
+-----------------+
| Brand |
| CA |
+-----------------+
| | |
| | +-------+
| | |Payment|
+----------------+ | | |Gateway| +----------------------+
| Issuer | | | | CA | | Acquirer |
| (User Home | +----------+ | +-------+ | (Broker) |
| Organization) | |Cardholder| | | | +----------------+ |
| | | CA | | +------+--+-{C} Payment | |
| | +----------+ | 3 | | Gateway | |
| | | | | +----------------+ |
| | | +---------+ | |
+----------------+ | | Merchant| +----------------------+
| | CA |
| +---------+
| |
+----------------+ | | +--------------------+
| Cardholder | | | | Merchant |
| (User) | | | | (Service Provider) |--+
| {C}-+-----+ | | | |
| | 1 +-----------+-{C} | |
| | 2 | | |
| | | | |
| | +--------------------+ |
| | | |
| | | Fulfillment |
| | | |
+----------------+ +---------------------+
Fig. 16 -- SET Trust Relationships within a Brand Domain
図16-ブランドドメイン内の信頼関係を設定する
- The Brand Organization operates a Brand CA and is therefore the holder of the common trust within the described domain. All involved parties (Cardholder, Issuer, Merchant and Acquirer) are members of the same trust domain. We will identify three separate CA's which issue a certificate on behalf of the Issuer, the Acquirer and the Brand Organization. The Brand CA, according to a tree like hierarchy, certifies all underlying CA's. The Brand CA obtains its trust from a single Root Certificate Authority. Before any party can obtain a Certificate from a CA, the party must have some form of contractual relationship.
- ブランド組織はブランドCAを運営しているため、説明されたドメイン内の共通信頼の保有者です。関与するすべての関係者（カード所有者、発行者、商人、買収者）は、同じ信頼ドメインのメンバーです。発行者、買収者、ブランド組織に代わって証明書を発行する3つの別々のCAを特定します。階層のようなツリーによると、ブランドCAは、基礎となるすべてのCAを証明しています。ブランドCAは、単一のルート証明書当局から信頼を得ています。CAから証明書を取得する前に、当事者は何らかの形の契約関係を持たなければなりません。
- After an account has been established with the Issuer, the Cardholder has to register with a Cardholder CA (CCA) through a series of registration steps (1) as defined in the SET protocol. If the CCA approves the registration, the Cardholder will obtain a Cardholder Certificate. The CCA may be operated by the Brand Organization on behalf of the Issuer. The Cardholder Certificate is an electronic representation of the payment card. This process creates a trust relationship between the Cardholder and the Brand. After the cardholder has received the Cardholder Certificate, the Cardholder is authorized to perform payments to an authorized Merchant.
- 発行者とともにアカウントが確立された後、カード所有者は、セットプロトコルで定義されている一連の登録手順（1）を通じてカード所有者CA（CCA）に登録する必要があります。CCAが登録を承認した場合、カード所有者はカード所有者証明書を取得します。CCAは、発行者に代わってブランド組織によって運営される場合があります。カード所有者証明書は、支払いカードの電子代表です。このプロセスは、カード所有者とブランドの間に信頼関係を作成します。カード所有者がカード所有者証明書を受け取った後、カード所有者は認可された販売者に支払いを行う権限を与えられます。
- After the Merchant has obtained a Merchant ID from the Acquirer, the Merchant has to register with the Merchant CA (MCA) through a series of registration steps (2) as defined in the SET protocol. If the MCA approves the registration, the Merchant will obtain a Merchant Certificate. This process creates a trust relationship between the Merchant and the Brand. The MCA may be operated by the Brand Organization on behalf of the Acquirer. After registration, the Merchant is authorized to accept payment requests from Cardholders and to send authorization requests to the Acquirer's Payment Gateway.
- 商人が取得者から商人IDを取得した後、商人は、セットプロトコルで定義されている一連の登録手順（2）を通じて商人CA（MCA）に登録する必要があります。MCAが登録を承認した場合、商人は商人証明書を取得します。このプロセスは、商人とブランドの間に信頼関係を作成します。MCAは、取得者に代わってブランド組織によって運営される場合があります。登録後、販売者は、カード所有者からの支払い要求を受け入れ、取得者の支払いゲートウェイに承認リクエストを送信する権限を与えられます。
- After the Acquirer has obtained a valid Bank Identification Number (BIN), the Acquirer must register with the Payment Gateway CA (PCA) in order to obtain a Payment Gateway Certificate (3). The Payment Gateway Certificate authorizes the Gateway to accept payment authorization requests originating from Merchants within its trust domain.
- 取得者が有効な銀行識別番号（BIN）を取得した後、取得者は支払いゲートウェイ証明書（3）を取得するために、支払いゲートウェイCA（PCA）に登録する必要があります。支払いゲートウェイ証明書は、その信頼ドメイン内の商人から発信される支払い承認要求を受け入れるためのゲートウェイを承認します。
- The Acquirer and Issuer have a trust relationship via the Brand Organization. The trust relationship is not ensured by procedures or a mechanism defined by SET, as this is a problem solved by agreements between financial organizations facilitating the payment service. Again, for simplicity, we assume that the relationship ensures that payment authorization requests received by the Acquirer's gateway will be forwarded in a secure and efficient way to the Issuer and its response is handled in the same way.
- 取得者と発行者は、ブランド組織を介して信頼関係を持っています。これは、支払いサービスを促進する金融組織間の契約によって解決される問題であるため、信頼関係は手順またはセットによって定義されたメカニズムによって保証されません。繰り返しになりますが、簡単にするために、この関係により、取得者のゲートウェイが受け取った支払い承認要求が発行者に安全で効率的な方法で転送され、その応答が同じ方法で処理されることを保証すると想定しています。
Note that there is no prior established static trust relationship between the Cardholder and the Merchant, as a Cardholder does not have to register with a Merchant or vice versa. The trust relationship is dynamically created during the communication process and is based on the common relationship with the Brand. By means of digital signatures using public key cryptography, the Cardholder's software is able to verify that the Merchant is authorized to accept the Brand Organization's credit card. The merchant is able to verify that the Cardholder has been authorized to use the Brand Organization's credit card.
カード所有者は商人に登録する必要がないため、またはその逆に登録する必要がないため、カード所有者と商人の間には以前に確立された静的信頼関係がないことに注意してください。信頼関係は、コミュニケーションプロセス中に動的に作成され、ブランドとの共通の関係に基づいています。公開キーの暗号化を使用したデジタル署名により、カード所有者のソフトウェアは、商人がブランド組織のクレジットカードを受け入れることを許可されていることを確認することができます。商人は、カード所有者がブランド組織のクレジットカードの使用を許可されていることを確認することができます。
The purchase request from Cardholder to Merchant and subsequent payment authorization exchange between Merchant and Acquirer is illustrated in figure 17 and described below.
カード所有者から商人への購入要求と、商人と買収者の間のその後の支払い承認交換を図17に示し、以下に説明します。
+----------------+ +------------------------+
| Issuer | | Acquirer |
| (User Home | | (Broker) |
| Organization) | | +------------------+ |
| |<------+--| Payment | |
| | 5 | | Gateway | |
| |-------+->| | |
| | 6 | +------------------+ |
| | | /|\ | |
+----------------+ +---------+---+----------+
|4 |7
| \|/
+----------------+ +--------------------+
| Cardholder | | Merchant |
| (User) | | (Service Provider) |---+
| |------>| | |
| | 1 | | |
| |<------| | |
| | 2 | | |
| |------>| | |
| | 3 | | |
| |<------| | |
| | 8 | | |
| | | | | |
| | +-----------------+--+ |
| | | |9 |
| |<--------| Fulfillment \|/ |
| | 10 | |
+----------------+ +----------------------+
Fig. 17 -- Communication Sequence
図17-通信シーケンス
1. The Cardholder shops and decides to purchase some goods at merchant.com. The Cardholder has selected a list of goods and the Merchant's software has subsequently prepared an order form for the Cardholder indicating the price, the terms and conditions, and the accepted payment methods. The SET transaction starts at the moment the Cardholder indicates that he or she wants to pay for the goods using a certain payment brand. The Cardholder software sends a request to the Merchant that initiates the payment process.
1. カード所有者はshopsショップであり、merchant.comでいくつかの商品を購入することにしました。カード所有者は商品のリストを選択し、その後、商人のソフトウェアは、価格、条件、および受け入れられた支払い方法を示すカード所有者の注文フォームを準備しました。セットトランザクションは、カード所有者が特定の支払いブランドを使用して商品の支払いを望んでいることを示している瞬間から始まります。カード所有者ソフトウェアは、支払いプロセスを開始する商人にリクエストを送信します。
2. The Merchant checks the order and signs it and returns it to the Cardholder including a certificate from the Acquirer's Gateway that allows the Cardholder to encrypt payment instructions that are only relevant to the Gateway and not to the Merchant (e.g., the Cardholder's credit card information). The Cardholder also includes his or her own certificate.
2. 商人は注文をチェックして署名し、カード所有者がゲートウェイにのみ関連し、商人に関連する支払い指示を暗号化できるようにする証明書を含むカード所有者に返送します（例えば、カードホルダーのクレジットカード情報）。カード所有者には、自分の証明書も含まれています。
3. The Cardholder now verifies both certificates (the software has the CA's root certificate). The Cardholder software generates a message containing the order information and the payment instructions that is signed by the Cardholder. Using the Gateway Certificate, it will encrypt the Payment Instruction so that it will only be readable by the Gateway. The Cardholder will include his or her certificate.
3. カード所有者は両方の証明書を検証します（ソフトウェアにはCAのルート証明書があります）。カード所有者ソフトウェアは、注文情報とカード所有者が署名する支払い指示を含むメッセージを生成します。ゲートウェイ証明書を使用すると、支払い命令を暗号化して、ゲートウェイによってのみ読み取り可能になります。カード所有者には、証明書が含まれます。
4. The Merchant verifies the Cardholder certificate and checks the message integrity. He or she will now process the payment and issue a payment authorization request to the gateway. The payment authorization request contains the Cardholder's certificate and both Merchant certificates.
4. 販売者は、カード所有者証明書を検証し、メッセージの整合性をチェックします。彼または彼女は今、支払いを処理し、ゲートウェイに支払い承認要求を発行します。支払い承認要求には、カード所有者の証明書と両方の商人証明書が含まれています。
5. The Gateway verifies the Merchant's signature certificate and that the Merchant signed the authorization request. Next it will obtain the account information and payment instructions and will check the message integrity and the Cardholder's certificate. If everything is in proper order it will send an authorization request to the Issuer via a secure bank network.
5. ゲートウェイは、商人の署名証明書を検証し、商人が承認要求に署名したことを確認します。次に、アカウント情報と支払い手順を取得し、メッセージの整合性とカード所有者の証明書を確認します。すべてが適切な順序である場合、安全な銀行ネットワークを介して発行者に承認要求を送信します。
6. The issuer returns the authorization.
6. 発行者は承認を返します。
7. The Acquirer's Gateway generates an authorization response which includes the gateway's certificate.
7. 取得者のゲートウェイは、ゲートウェイの証明書を含む承認応答を生成します。
8. The Merchant checks the authorization response and completes the process by forwarding a purchase response to the Cardholder.
8. マーチャントは、認証応答をチェックし、カード所有者に購入応答を転送することによりプロセスを完了します。
9. The Merchant software authorizes the delivery of the purchased goods.
9. マーチャントソフトウェアは、購入した商品の配送を承認します。
10. The Cardholder receives the purchased goods.
10. カード所有者は購入した商品を受け取ります。
In the previous "single" domain case we already assume that there are multiple Cardholders, Merchants, Issuers and Acquirers. However all these parties belong to a single trust domain as there is only a single CCA, MCA and PCA. The trust relationship between multiple cardholders and multiple Issuers go via a single CCA in the same way as the trust relationship between an Acquirer and a Merchant uses the same MCA. The multi-domain case arises when there are multiple domains of CCA's, MCA's and PCA's. In SET these domains reside under a particular Geopolitical CA (GCA) which is illustrated in figure 18.
以前の「シングル」ドメインケースでは、複数のカード所有者、商人、発行者、取得者がいると既に想定しています。ただし、これらのすべての関係者は、CCA、MCA、PCAが1つしかないため、単一の信頼ドメインに属します。複数のカード所有者と複数の発行者の間の信頼関係は、取得者と商人の間の信頼関係が同じMCAを使用するのと同じように、単一のCCAを介して進みます。CCA、MCA、PCAの複数のドメインがある場合、マルチドメインのケースが発生します。これらのドメインは、図18に示す特定の地政学的CA（GCA）の下にあります。
+-----------+
| Root CA |
| |
+-----------+
|
|
+----------------------|-------------------------------+
+-----------------------------------------------------+ |
| Brand CA | |
| |-+
+-----------------------------------------------------+
|
|
+----------------------|-------------------------------+
+-----------------------------------------------------+ |
| Geopolitical CA | |
| |-+
+-----------------------------------------------------+
| | |
| | |
+----|--------+ +---|-------+ +-------|----------+
+------------+ | +----------+ | +-----------------+ |
| Cardholder | | | Merchant | | | Payment Gateway | |
| CA |-+ | CA |-+ | CA |-+
+------------+ +----------+ +-----------------+
Fig. 18 -- SET Certificate Management Architecture
図18-証明書管理アーキテクチャの設定
A GCA may represent a country or region. The architecture defines a trust hierarchy needed to manage and verify SET Certificates as these need to be issued, renewed or revoked. Each geopolitical region may have different policies for issuing, renewing or revoking certificates. However once certificates have been issued, Cardholders and Merchants belonging to different GCA's can still be recognized as belonging to the same Brand. This will allow a European Cardholder to purchase goods in the U.S. The U.S. Acquirer's gateway will recognize that the Cardholder belongs to the same Brand and will therefore accept a payment authorization request.
GCAは国または地域を表す場合があります。アーキテクチャは、これらを発行、更新、または取り消す必要があるため、設定された証明書を管理および検証するために必要な信頼階層を定義します。各地政学的地域には、証明書を発行、更新、または取り消すためのさまざまなポリシーがある場合があります。ただし、証明書が発行されると、異なるGCAに属するカード所有者と商人は、同じブランドに属すると認識されます。これにより、ヨーロッパのカード所有者が米国で商品を購入できるようになります。米国の買収者のゲートウェイは、カード所有者が同じブランドに属していることを認識し、したがって支払い承認要求を受け入れます。
Many e-commerce environments do not use SET. Other mechanisms exist based on SSL, XML, and S/MIME. Also a mechanism that uses SET only for the payment authorization to the Gateway exists and is known as half SET. However, using the model described in this document, we can derive a fairly comprehensive set of protocol requirements for e-commerce. In these requirements, the SET terms are replaced again by the descriptive model terms:
多くのeコマース環境はセットを使用しません。SSL、XML、およびS/MIMEに基づいて、他のメカニズムが存在します。また、ゲートウェイへの支払い承認にのみセットを使用するメカニズムが存在し、ハーフセットとして知られています。ただし、このドキュメントで説明されているモデルを使用して、eコマースのプロトコル要件のかなり包括的なセットを導き出すことができます。これらの要件では、設定された用語は、説明的なモデル用語に再び置き換えられます。
Cardholder = User Merchant = Service Provider Issuer = User Organization Acquirer = Broker
cardholder = user merchant = service provider issuer = user organization accoirer = broker
1. The Authorization mechanism must allow trust relationships to be established before any requests can be made from the User to the Service Provider and from the Service Provider via a Broker to the User Organization. This process will enable the parties to communicate securely by creating an authenticated channel and, by so doing, implicitly authorizing its usage.
1. 承認メカニズムは、ユーザーからサービスプロバイダー、およびブローカーを介してサービスプロバイダーからユーザー組織へのリクエストを行う前に、信頼関係を確立することを許可する必要があります。このプロセスにより、当事者は認証されたチャネルを作成し、そうすることにより、暗黙的にその使用を許可することにより、安全にコミュニケーションをとることができます。
2. Upon receipt of any request or response, entities need to be able to verify whether the transmitting party is still authorized to send this request or response.
2. リクエストまたは応答を受け取ると、エンティティは、この要求または応答を送信することを依然として許可されているかどうかを確認できる必要があります。
3. The User must be able to authorize the Service Provider to request an authorization from the User Home Organization.
3. ユーザーは、ユーザーホーム組織から許可を要求するようサービスプロバイダーに承認できる必要があります。
4. The User must be able to authorize fulfillment of a proposed service offer from the Service Provider.
4. ユーザーは、サービスプロバイダーから提案されたサービスオファーの履行を承認できる必要があります。
Other requirements related to the authorization process:
承認プロセスに関連するその他の要件：
Integrity
誠実さ
5. For any authorization request or response, the receiving party needs to verify that the content of the message has not been altered.
5. 承認要求または応答のために、受信者はメッセージのコンテンツが変更されていないことを確認する必要があります。
Confidentiality/Privacy
機密性/プライバシー
6. The User must be able to pass information relevant to the session authorization process to the User Home Organization via a Broker and the Service Provider without allowing the Broker or the Service Provider to examine its content.
6. ユーザーは、ブローカーまたはサービスプロバイダーがそのコンテンツを調べることなく、ブローカーとサービスプロバイダーを介して、セッション承認プロセスに関連する情報をユーザーホーム組織に渡すことができる必要があります。
7. The User Home Organization must be able to communicate information relevant to the session authorization via the Broker and the Service Provider to the User without allowing the Broker or the Service Provider to examine its content.
7. ユーザーホーム組織は、ブローカーまたはサービスプロバイダーがそのコンテンツを調べることなく、ブローカーとサービスプロバイダーを介してセッション承認に関連する情報をユーザーに伝えることができなければなりません。
Nonrepudiation
非繰り返し
8. There is a need for a recorded, authenticated and authorized agreement about the request for and delivery of service.
8. サービスの要求と提供に関する記録された、認証された認証された承認された契約が必要です。
This section describes the authorization aspects of computer based distance learning environments. In this section we will model the relationships and working practices in a hypothetical university environment where a student enrolls in courses, attends lectures, and takes the corresponding exams from remote locations (distance learning) or via computer equipment (computer based education). When completed successfully, a student is authorized to enroll in a set of subsequent courses according to his or her curriculum requirements. Completion of required courses with passing grades results in graduation.
このセクションでは、コンピューターベースの遠隔学習環境の承認の側面について説明します。このセクションでは、学生がコースに登録し、講義に出席し、リモートロケーション（遠隔学習）またはコンピューター機器（コンピューターベースの教育）から対応する試験を受ける仮想大学環境での関係と労働慣行をモデル化します。正常に完了すると、学生はカリキュラムの要件に従って、その後の一連のコースに登録する権限があります。成績が合格した必要なコースの完了により、卒業が発生します。
Although this section specifically describes an example of a student taking courses at a faculty (department) of the university, the resulting requirements should also be valid for other applications in similar environments, e.g. library loans, electronic abstract and reprint services, computer and network access, use of copy machines, budget management, store retrievals, use of coffee machines and building access.
このセクションでは、学生が大学の教員（部門）でコースを受講する例を具体的に説明していますが、結果の要件は、同様の環境の他のアプリケーションにも有効である必要があります。図書館ローン、電子抽象および転載サービス、コンピューターおよびネットワークアクセス、コピー機の使用、予算管理、店舗検索、コーヒーマシンの使用、建物アクセス。
It is important to recognize that the AAA environment we are describing also needs to be managed. For example, for an application such as budget management, it is necessary to delegate budget authority from a central financial department to budget managers in education or faculty groups. An AAA environment must allow creation of policy rules either by certain individuals or by other AAA servers with authorization to do so.
私たちが説明しているAAA環境も管理する必要があることを認識することが重要です。たとえば、予算管理などのアプリケーションの場合、中央財務部門から教育機関または教員グループの予算管理者に予算当局を委任する必要があります。AAA環境は、特定の個人または他のAAAサーバーによって、そのための許可を持つ他のAAAサーバーによるポリシールールの作成を許可する必要があります。
The establishment of the model involves four steps:
モデルの確立には4つのステップが含まれます。
1. identification of the components that are involved and what they are called in this specific environment,
1. 関係するコンポーネントの識別と、この特定の環境でそれらが呼ばれるもの、
2. identification of the contractual relationships between the involved parties,
2. 関係者間の契約上の関係の特定、
3. identification of the relationships that are based on trust, and
3. 信頼に基づいている関係の特定、および
4. consideration of the sequence of messages exchanged between components.
4. コンポーネント間で交換される一連のメッセージの考慮。
We will consider the components of a distance learning environment in the context of the conceptual entities defined in [2].
[2]で定義されている概念エンティティのコンテキストで、遠隔学習環境のコンポーネントを検討します。
- The Student (User) -- the person enrolling in a course (Service) and taking the corresponding exam.
- 学生（ユーザー） - コース（サービス）に登録し、対応する試験を受ける人。
- The Educator (Service Equipment) -- the education content server for which the content is delivered by the Professor.
- 教育者（サービス機器） - 教授によってコンテンツが配信される教育コンテンツサーバー。
- The Educator Authorization Module (Service Provider AAA Server). This module must check at the service access point whether the student complies with the requirements for enrolling in the course. The authorization may be based on both local (by the professor) and remote policies (originating from the faculty). Rules must allow enough flexibility to prevent students from being falsely denied access to courses. Strict rules must only be applied at graduation time.
- 教育者認証モジュール（サービスプロバイダーAAAサーバー）。このモジュールは、学生がコースに登録するための要件に準拠しているかどうかをサービスアクセスポイントで確認する必要があります。許可は、ローカル（教授）と遠隔ポリシー（教員から発信される）の両方に基づいている場合があります。ルールは、学生がコースへのアクセスを誤って拒否されないようにするために、十分な柔軟性を可能にする必要があります。厳格なルールは、卒業時にのみ適用する必要があります。
- The Faculty (Service Provider) -- the organization (department in U.S. terms) which controls the Service "Equipment" of which the Educator is one example.
- 教員（サービスプロバイダー） - 教育者がその一例であるサービスの「機器」を管理する組織（米国の条件）。
- The Curriculum Commission (Part of User Home Organization) -- body responsible for creating rules by which a student is allowed to enroll in a certain course and how this course will count toward his or her graduation requirements. Students may legally take any course available at any time, however the Curriculum Commission will decide whether this course will contribute towards their graduation. When a Student registers with a certain Educator, the Educator may check with the Curriculum Commission AAA server whether the course will count towards graduation and confirm this with the student.
- カリキュラム委員会（ユーザーホーム組織の一部） - 学生が特定のコースに登録することを許可され、このコースが卒業要件にカウントされるルールを作成する責任者。学生はいつでも利用可能なコースを合法的に受講することができますが、カリキュラム委員会は、このコースが卒業に貢献するかどうかを決定します。学生が特定の教育者と登録すると、教育者はカリキュラム委員会のAAAサーバーに、コースが卒業にカウントされるかどうかを確認し、学生と一緒にこれを確認することができます。
- The Student Administration (Part of User Home Organization) -- the administrative organization that authorizes students to enroll in courses if certain criteria, including financial criteria, are met. Next to the student, the Student Administration will keep track of any exam results for the student and will issue a graduation certificate when all criteria are met.
- 学生管理（ユーザーホーム組織の一部） - 財務基準を含む特定の基準が満たされている場合、学生がコースに登録することを学生に承認する管理組織。学生の隣で、学生管理は学生の試験結果を追跡し、すべての基準が満たされたときに卒業証明書を発行します。
Contractual relationships are illustrated in figure 19, below. Based on contract relationships,specific trust relationships are created as required.
契約上の関係を以下の図19に示します。契約関係に基づいて、特定の信頼関係が必要に応じて作成されます。
Although not shown in figure 19, it is assumed that the university has contractual relationships with the faculties in which every faculty is allowed and obligated to build, maintain and present one or more specific studies.
図19には示されていませんが、大学はすべての教員が許可され、1つ以上の特定の研究を構築、維持、提示することが許可され、義務付けられている学部と契約上の関係を持っていると想定されています。
+---------------------------------------------+
| +-----------------------------------------+ |
| | Faculty administration | |
| |+----------------+ +----------------+| |
| |O Student | | Curriculum || |
| *| Administration O*****O Commission || |
|*|| AAA Server | | AAA Server || |
*/|+---O------O-----+ +-----O------O---+| |
*//| * * * * | |
*// +----*---------*-----------*---------*----+ |
*//| * || * * || * |
*// | * || * * || * |
*// | * || * || * |
*// | * || * * || * |
*// | * || * * || * |
*// | +----*---------*--+ +--*---------*----+ |
*// | | * * | | * * |
*// | |+---O------O----+| |+----O------O---+| |
*// | || Educator A || || Educator B || |
*// | || AAA Server || || AAA Server || |
*// | || Service admin.|| || Service admin.|| |
*// | |+---O-----------+| |+-----------O---+| |
*// | | * | | * | |
+-O-------+ | | * | | * | |
| | | |+---O-----------+| |+-----------O---+| |
| Student | | || Educator || || Educator || |
| | | || Course A || || Course B || |
| | | |+---------------+| |+---------------+| |
+---------+ | +-----------------+ +-----------------+ |
| Faculty |
+---------------------------------------------+
// = contractual relationship
** = trust relationship
Fig. 19 -- Contractual relationships - single domain case
図19-契約関係 - 単一ドメインケース
As shown in figure 19, the Student has a contractual relationship with the Faculty. The contract allows the Student to pursue a course of study consisting of a set of courses. Courses are presented to the Students by the Educators. A course of study may consist of courses from different Faculties.
図19に示すように、学生は教員と契約上の関係を持っています。この契約により、学生は一連のコースで構成される一連の学習を追求することができます。コースは、教育者によって学生に提示されます。調査コースは、さまざまな学部のコースで構成される場合があります。
Faculties have contracts among them allowing Students from one Faculty to enroll in courses from other Faculties.
学部には、ある学部の学生が他の学部のコースに登録できるようにする契約があります。
Faculties instantiate Educators based on a contract between the Faculty Administration and the professor implementing and managing the Educator. Authorization is based on policy rules defined by one or more parties in the contractual relationships. For example, a professor has a policy to give the course only in the afternoon and the Faculty has a policy to give the course to their own students and students from faculty-x but not, when oversubscribed, to faculty-y students.
学部は、教員と教育者の実施と管理の教授との契約に基づいて、教育者をインスタンス化します。承認は、契約関係における1つ以上の当事者によって定義されたポリシールールに基づいています。たとえば、教授は午後にのみコースを提供するポリシーを持っています。教員は、教員から学生と学生にコースを提供するポリシーを持っていますが、過剰に登録されたとき、教員のような学生にはそうではありません。
Figure 19 illustrates relevant trust relationships which statically enable AAA entities to communicate certain attributes in our simplified example. However, in order for the illustrated entities to work, other trust relationships that are not illustrated must already be in existence:
図19は、AAAエンティティが単純化された例で特定の属性を静的に伝えることができる関連する信頼関係を示しています。ただし、図解されたエンティティが機能するためには、説明されていない他の信頼関係はすでに存在している必要があります。
- A trust relationship based on a contract between the Faculty and the university enables a faculty to create and teach specific courses belonging to a course of study.
- 教員と大学との契約に基づく信頼関係により、教員は一連の学習に属する特定のコースを作成および教えることができます。
- Although not further detailed in this example, it is worth noting that trust relationships between faculties authorize students from one faculty to enroll in courses with other faculties.
- この例ではそれほど詳細ではありませんが、学部間の信頼関係は、ある教員の学生が他の学部とのコースに登録することを許可していることは注目に値します。
- A professor responsible for the content of the Educator has a trust relationship with the administration of the faculty. Through this relationship, the faculty enables the professor to teach one or more courses fitting the requirements of the Curriculum Commission.
- 教育者の内容を担当する教授は、教員の管理と信頼関係を持っています。この関係を通じて、教授は教授がカリキュラム委員会の要件に適合する1つ以上のコースを教えることができます。
Figure 19 illustrates the following trust relationships:
図19は、次の信頼関係を示しています。
- When a person wants to become a Student of a Faculty, the contract requires the Student to register with the Student Administration of the Faculty. If the requirements for registration are met, a trust relationship with the Faculty enables the Student to register for courses. For this purpose, the Student Administration will issue a student card which contains a student ID and information about the Faculty he or she is admitted to. The Student Administration will only admit Students who pay the necessary fees and have met certain prerequisites. The Student Administration will also keep track of Student grades and will ultimately issue a certificate at graduation. The Student Administration AAA server has access to relevant student data and will only issue grade information and other student-related information to authorized parties which have a specified means of authenticating.
- 人が教員の学生になりたい場合、契約は学生が教員の学生管理に登録することを要求します。登録の要件が満たされている場合、教員との信頼関係により、学生はコースに登録できます。この目的のために、学生管理者は、学生IDと入院している教員に関する情報を含む学生カードを発行します。学生管理者は、必要な料金を支払い、特定の前提条件を満たした学生のみを認めます。学生管理はまた、学生の成績を追跡し、最終的に卒業時に証明書を発行します。学生管理AAAサーバーは、関連する学生データにアクセスでき、認証の指定された手段を持つ認可された関係者に、成績情報やその他の学生関連情報のみを発行します。
- The Curriculum Commission AAA server needs a trust relationship with the Student Administration AAA server in order to obtain grade information to check whether a student has met the required course prerequisites. The Curriculum Commission creates certain rules within its AAA server which are evaluated when a particular student attempts to register for a particular course in order to give an advisory to the student.
- カリキュラム委員会AAAサーバーは、学生が必要なコースの前提条件を満たしているかどうかを確認するためにグレード情報を取得するために、学生管理AAAサーバーとの信頼関係を必要とします。カリキュラム委員会は、特定の学生が学生にアドバイザリーを提供するために特定のコースに登録しようとするときに評価されるAAAサーバー内に特定のルールを作成します。
- The Educator AAA server needs a trust relationship with the Student Administrator AAA server in order to verify whether this particular Student is in good standing with the Faculty. Only authorized Educator AAA servers may send requests to the Student Administration AAA server.
- 教育者AAAサーバーは、この特定の学生が教員と良好な状態にあるかどうかを確認するために、学生管理者AAAサーバーとの信頼関係を必要としています。許可された教育者AAAサーバーのみが、学生管理AAAサーバーにリクエストを送信できます。
- The Educator AAA server needs a trust relationship with the Curriculum Commission AAA server in order to allow the Educator to obtain an advisory for the Student whether this course is consistent with his or her curriculum or whether the student meets the course prerequisites. Only authorized Educator AAA servers may send requests to the Curriculum AAA Server.
- 教育者AAAサーバーは、このコースが自分のカリキュラムと一致しているか、学生がコースの前提条件を満たしているかどうかにかかわらず、教育者が学生のアドバイザリーを取得できるようにするために、カリキュラム委員会AAAサーバーとの信頼関係を必要としています。認定された教育者AAAサーバーのみが、カリキュラムAAAサーバーにリクエストを送信できます。
For the sake of simplicity, we take the example of a student from the same faculty as the professor.
簡単にするために、私たちは教授と同じ教員の学生の模範を考えます。
In this example the following interactions take place for a hypothetical course (see figure 20).
この例では、仮想コースで次の相互作用が行われます（図20を参照）。
+----------------------------------------------+
| |
| +----------------+ 6 +----------------+ |
| | Student |----->| Curriculum | |
| | Administration |<-----| Commission | |
| | AAA Server | 5 | AAA Server | |
| +----------------+ _ +----------------+ |
| /|\ | /|/ |
| | | / / |
| 2,8| |3 / /6 |
| | | 4/ / |
| | | / / |
| | | / / |
| | \|/ /|/ |
| +---------------+ -- +---------------+ |
| | Educator A | | Educator B | |
| | AAA Server | | AAA Server | |
| +---------------+ +---------------+ |
| /|\ | |
|2,4,8| |3,6 |
+---------+ | | \|/ |
| | 1,7 | +---------------+ +---------------+ |
| Student |------->| Educator | | Educator | |
| |<-------| Course A | | Course B | |
| | 7,8 | +---------------+ +---------------+ |
+---------+ | Faculty |
+----------------------------------------------+
Fig. 20 -- AAA transactions - single domain case
図20-AAAトランザクション - 単一ドメインケース
1. After the Professor has set up the Service Equipment (Educator) students come to it presenting their ID (college card, name+faculty) and ask to be admitted to the course.
1. 教授がサービス機器（教育者）の学生がID（カレッジカード、名前の教員）を提示してそれに来て、コースに入院するように頼んだ後。
2. The Educator checks the ID to determine it is indeed dealing with a student from the faculty. This can include a check with the Student Administration.
2. 教育者は、IDをチェックして、それが実際に教員の学生を扱っていると判断します。これには、学生管理のチェックが含まれます。
3. The Student Administration replies to the Educator AAA Server, and the Educator AAA Server replies to the Educator.
3. 学生管理者は教育者AAAサーバーに返信し、教育者AAAサーバーは教育者に返信します。
4. The Educator checks the request of the Student against its own policy (courses only in the afternoon) and checks with the Curriculum Commission whether this student is advised to take the course. The necessary information is not normally known to or maintained by the professor.
4. 教育者は、学生の要求を独自のポリシー（午後のみ）に対してチェックし、カリキュラム委員会にこの学生がコースを受講するように勧められるかどうかを確認します。必要な情報は、通常、教授によって知られていない、または維持されていません。
5. The Curriculum Commission may check against the Student Administration to see if the Student had the necessary grades for the previous courses according to the policies set by the Curriculum Commission.
5. カリキュラム委員会は、カリキュラム委員会によって設定されたポリシーに従って、学生が以前のコースに必要な成績を持っているかどうかを確認するために、学生管理者に対してチェックすることができます。
6. The Student Administration replies to the Curriculum Commission, the Curriculum Commission replies to the Educator AAA Server, and the Educator AAA Server replies to the Educator.
6. 学生管理はカリキュラム委員会に返信し、カリキュラム委員会は教育者AAAサーバーに返信し、教育者AAAサーバーは教育者に返信します。
7. If now authorized, the Student is presented the material and the Student returns completed exams.
7. 現在許可されている場合、学生は資料を提示され、学生は完了した試験を返します。
8. If the Student passes the tests, the Educator informs both the Student and the Student Administration that the Student has passed.
8. 学生がテストに合格した場合、教育者は学生と学生の両方の管理者に学生が合格したことを通知します。
We identify the following requirements for an AAA server environment for this example:
この例については、AAAサーバー環境の次の要件を特定します。
1. It must be possible to delegate authority to contracted partners. Although this requirement is not explicit in the limited example, the relationship between University and Faculty may require delegation of authority regarding the curriculum to the Faculty. In the case of budget management, this requirement is evident.
1. 契約されたパートナーに権限を委任することは可能でなければなりません。この要件は限られた例では明示的ではありませんが、大学と教員の関係は、教員へのカリキュラムに関する権限の委任を必要とする場合があります。予算管理の場合、この要件は明らかです。
2. A system to manage the delegated authority must be established. It is possible that this is just another AAA server environment. This comes from the fact that one partner requires the presence of specific rules to be in the AAA server of another partner. For example, the Faculty must be sure that certain checks are performed by the Educator's AAA server.
2. 委任された当局を管理するシステムを確立する必要があります。これが単なる別のAAAサーバー環境である可能性があります。これは、あるパートナーが別のパートナーのAAAサーバーにあるために特定のルールの存在を必要とするという事実に由来しています。たとえば、教員は、教育者のAAAサーバーによって特定のチェックが実行されることを確認する必要があります。
3. AAA requests must either be evaluated at the AAA server queried or else parts of the request must be forwarded to another AAA server which can decide further on the request. As such, it must be possible to build a network of AAA servers in which each makes the decisions it is authorized to make by the relationships among the entities, e.g., a request from the Educator to the Curriculum Commission may result in a request to the Student Administration.
3. AAAリクエストは、AAAサーバーで評価されるか、リクエストの一部を別のAAAサーバーに転送する必要があります。そのため、AAAサーバーのネットワークを構築することが可能である必要があります。これにより、それぞれがエンティティ間の関係によって承認される決定を下すことができる必要があります。たとえば、教育者からカリキュラム委員会への要求は、学生管理。
4. Transaction logs must be maintained to support non-repudiation for the grades of the students. This recording should be time-stamped and allow signing by authorized entities. A student should sign for taking an exam and this should be kept by the Educator's AAA server. After grading, the professor should be able to sign a grade and send it to the Student Administrator and the Student Administrator's AAA server should log and timestamp this event.
4. トランザクションログは、学生の成績の非repudiationをサポートするために維持する必要があります。この録音は時間刻み付けられており、認定されたエンティティによる署名を許可する必要があります。学生は試験を受けるために署名する必要があります。これは、教育者のAAAサーバーが保持する必要があります。グレーディング後、教授はグレードに署名して学生管理者に送信でき、学生管理者のAAAサーバーはこのイベントを記録してタイムスタンプする必要があります。
5. Three types of AAA messages are required:
5. 3種類のAAAメッセージが必要です。
- authorization requests and responses for obtaining authorization, - notification messages for accounting purposes, and - information requests and responses for getting information regarding the correct construction of requests and for querying the database of notifications.
- 許可リクエストと応答認証、会計目的のための通知メッセージ、およびリクエストの正しい構築に関する情報を取得し、通知のデータベースを照会するための情報リクエストと回答。
The authorization applications discussed in this document are modeled on the framework presented in [2]. Security considerations relative to the authorization framework are discussed in [2].
このドキュメントで説明されている承認アプリケーションは、[2]で提示されているフレームワークでモデル化されています。認証フレームワークに関するセキュリティ上の考慮事項については、[2]で説明します。
Specific security aspects of each authorization application presented in this document are discussed in the relevant section, above.
このドキュメントに記載されている各認証アプリケーションの特定のセキュリティの側面については、上記の関連セクションで説明します。
Security aspects of the applications, themselves, are discussed in the references cited below.
アプリケーション自体のセキュリティの側面については、以下の参照で説明します。
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. [14]
セキュリティ協会 - セキュリティコンテキストのコレクションは、それらの間で交換されるプロトコルメッセージに適用される可能性のあるノードのペア間です。各コンテキストは、認証アルゴリズムとモード、秘密（共有キー、または適切なパブリック/秘密キーペア）、および使用中のリプレイ保護スタイルを示します。[14]
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] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Framework", RFC 2904, August 2000.
[2] Vollebrecht、J.、Calhoun、P.、Farrell、S.、Gommans、L.、Gross、G.、De Bruijn、B.、De Laat、C.、Holdrege、M。and D. Spence、 "AAA Authorization Framework"、RFC 2904、2000年8月。
[3] Farrell, S., Vollbrecht, J., Calhoun, P., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Requirements", RFC 2906, August 2000.
[3] 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月。
[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] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[5] Aboba、B。およびG. Zorn、「ローミングプロトコルを評価するための基準」、RFC 2477、1999年1月。
[6] Beadles, Mark Anthony, and David Mitton, "Criteria for Evaluating Network Access Server Protocols", Work in Progress.
[6] Beadles、Mark Anthony、およびDavid Mitton、「ネットワークアクセスサーバープロトコルを評価するための基準」が進行中です。
[7] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[7] Aboba、B。およびM. Beadles、「ネットワークアクセス識別子」、RFC 2486、1999年1月。
[8] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[8] Rigney、C.、Rubens、A.、Simpson、W。and S. Willens、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2138、1997年4月。
[9] Calhoun, P. and G. Zorn, "Roamops Authentication/Authorization Requirements", Work in Progress.
[9] Calhoun、P。and G. Zorn、「Roamops認証/認証要件」、進行中の作業。
[10] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[10] Perkins、C。、「IP Mobility Support」、RFC 2002、1996年10月。
[11] Glass, Steven, et al, "Mobile IP Authentication, Authorization, and Accounting Requirements", Work in Progress.
[11] Glass、Stevenなど、「モバイルIP認証、承認、会計要件」、進行中の作業。
[12] Hiller, Tom, et al., "cdma2000 Wireless Data Requirements for AAA", Work in Progress.
[12] Hiller、Tom、et al。、「AAAのCDMA2000ワイヤレスデータ要件」、作業進行中。
[13] Neilson, Rob, Jeff Wheeler, Francis Reichmeyer, and Susan Hares, "A Discussion of Bandwidth Broker Requirements for Internet2 Qbone Deployment", ver. 0.7, August 1999, http://www.merit.edu/working.groups/i2-qbone-bb/doc/BB_Req7.pdf.
[13] Neilson、Rob、Jeff Wheeler、Francis Reichmeyer、Susan Hares、「インターネット2 Qbone展開の帯域幅のブローカー要件の議論」、Ver。0.7、1999年8月、http：//www.merit.edu/working.groups/i2-qbone-bb/doc/bb_req7.pdf。
[14] deBry, R., "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999.
[14] Debry、R。、「インターネット印刷プロトコル/1.0：モデルとセマンティクス」、RFC 2566、1999年4月。
[15] Burdett, D., "Internet Open Trading Protocol - IOTP", RFC 2801, April 2000.
[15] Burdett、D。、「インターネットオープントレーディングプロトコル-IOTP」、RFC 2801、2000年4月。
[16] "SET Secure Electronic Transaction Specification Book 1: Business Description", Version 1.0, May 31, 1997, http://www.setco.org/download/set_bk1.pdf.
[16] 「安全な電子トランザクション仕様のセットブック1：ビジネス説明」、バージョン1.0、1997年5月31日、http：//www.setco.org/download/set_bk1.pdf。
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
EMail: 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
Leon Gommans Enterasys Networks Emea Kerkplein 24 2841 XM Moordrecht The Netherlands
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
MattRege 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
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エディター機能の資金は現在、インターネット協会によって提供されています。