RFC2905 日本語訳
2905 AAA Authorization Application Examples. J. Vollbrecht, P.Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat,M. Holdrege, D. Spence. August 2000. (Format: TXT=118645 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Vollbrechtがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2905はネットワークInc.カテゴリを連結します: 情報のP.のHoldrege ipVerse D.スペンスInterlink Networks Inc.カルフーンサン・マイクロシステムズ・インクS.ファレルボルチモアTechnologies L.Gommans Enterasys Networks EMEA G.GrossルーセントテクノロジーズB.de Bruijn InterpayネーデルラントB.V.C.de Laatユトレヒト大学M.2000年8月
AAA Authorization Application Examples
AAA承認アプリケーションの例
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This memo 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.
このメモは承認を必要とするアプリケーションに関するいくつかの例について説明します。 一貫したフレームワークで各アプリケーションについて説明します、そして、それぞれのアプリケーションの特定の承認要件を与えます。 この材料をアプリケーションに責任があるワーキンググループが寄付しないで、アプリケーションがどう彼らの承認需要を満たすかに規範的であると考えるべきではありません。 むしろ意図は承認プロトコルが、一般に、役に立つように会う必要があるという要件のセットをコンパイルする意見でさまざまな異なったアプリケーションの基本的な必要物について調査することです。
Vollbrecht, et al. Informational [Page 1] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [1ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
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
1. 序論… 3 2. ローミングがあるppp Dialin… 4 2.1. 描写的であるモデル… 4 2.2. 承認要件… 6 3. モバイルIP… 6 3.1. フレームワークとの関係… 10 3.2. インターネット縦断を最小にします… 10 3.3. 主要な分配… 10 3.4. モバイルIP承認要件… 11 4. 帯域幅ブローカー… 12 4.1. 記述をモデル化してください… 13 4.2. 2層のコンポーネントはモデル化されます… 13 4.3. 契約上の関係の識別… 13 4.3.1. 単一領域ケース… 14 4.3.2. マルチドメインケース… 15 4.4. 信頼関係の識別… 16 4.5. コミュニケーションモデルと信頼関係… 18 4.6. 帯域幅ブローカーコミュニケーションはモデル化されます… 19 4.6.1. 概念… 19 4.6.1.1. イントラドメイン承認… 19 4.6.1.2. 相互ドメイン承認… 19 4.6.2. 帯域幅ブローカー仕事フェーズ… 20 4.6.3. 相互ドメインシグナリング… 20 4.6.3.1. フェーズ0… 20 4.6.3.2. フェーズ1… 20 4.6.4. 帯域幅ブローカー通信アーキテクチャ… 22 4.6.5. 2層の相互ドメインモデル… 23 4.6.5.1. セッション初期設定… 23 4.6.5.2. セットアップを修理してください… 23 4.6.5.3. キャンセルを修理してください… 24 4.6.5.4. Renegotiationを調整してください… 24 4.6.5.5. RARとRAA… 24 4.6.5.6. セッションメインテナンス… 24 4.6.5.7. イントラドメイン界面プロトコル… 24 4.7. 要件… 24 5. インターネット印刷… 25 5.1. 関係を信じてください… 26 5.2. 属性証明書の使用… 27 5.3. IPPと承認記述的モデル… 28 6. 電子通商… 29 6.1. 記述をモデル化してください… 30 6.1.1. コンポーネントの識別… 30 6.1.2. 契約上の関係の識別… 31 6.1.3. 信頼関係の識別… 32 6.1.3.1. 静的な信頼関係… 33 6.1.3.2. ダイナミックな信頼関係… 35
Vollbrecht, et al. Informational [Page 2] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [2ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
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
6.1.4. コミュニケーションモデル… 35 6.2. マルチドメインモデル… 37 6.3. 要件… 38 7. コンピュータ利用教育と距離学習… 40 7.1. 記述をモデル化してください… 40 7.1.1. コンポーネントの識別… 40 7.1.2. 契約上の関係の識別… 41 7.1.3. 信頼関係の識別… 43 7.1.4. 要求の系列… 44 7.2. 要件… 46 8. セキュリティ問題… 47用語集… 47の参照箇所… 48人の作者のアドレス… 50 完全な著作権宣言文… 53
1. Introduction
1. 序論
This document is one of a series of three documents under consideration by the AAAarch RG dealing with the authorization requirements for AAA protocols. The three documents are:
このドキュメントはAAAプロトコルのための承認要件に対処するAAAarch RGによる考慮での一連の3通のドキュメントの1つです。 3通のドキュメントは以下の通りです。
AAA Authorization Framework [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]に提示された要件を動機づけることです。 整列には承認アプリケーションに責任がある様々なワーキンググループの仕事がイラスト入りでこの仕事があることを意図します。 しかしながら、このメモを例証されたアプリケーションのどれかに正式であると見なすべきではありません。 信頼すべき文書が存在しているか、または開発中であるところでは、それらはこのドキュメントの端での参照に記載されています。
Vollbrecht, et al. Informational [Page 3] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [3ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
The work for this memo was done by a group that originally was the Authorization subgroup of the AAA Working Group of the IETF. When the charter of the AAA working group was changed to focus on MobileIP and NAS requirements, the AAAarch Research Group was chartered within the IRTF to continue and expand the architectural work started by the Authorization subgroup. This memo is one of four which were created by the subgroup. This memo is a starting point for further work within the AAAarch Research Group. It is still a work in progress and is published so that the work will be available for the AAAarch subgroup and others working in this area, not as a definitive description of architecture or requirements.
このメモのための仕事が元々IETFのAAA作業部会のAuthorizationサブグループであったグループによって行われました。 MobileIPとNAS要件に焦点を合わせるためにAAAワーキンググループの特許を変えたとき、Authorizationサブグループによって始められた建築仕事を続けて、広げるためにIRTFの中でAAAarch Research Groupをチャーターしました。 このメモはサブグループによって作成された4の1つです。 このメモはAAAarch Research Groupの中のさらなる仕事のための出発点です。 それは、仕事がアーキテクチャか要件の決定的な記述ではなく、この領域で働いているAAAarchサブグループと他のものに利用可能になるように、それでも、処理中の作業であり、発行されます。
This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their negatives, in the way described in RFC 2119 [4].
このドキュメントはRFC2119[4]に述べられた方法で用語'MUST'、'SHOULD'、および'5月'、およびそれらのネガを使用します。
2. PPP Dialin with Roaming
2. ローミングがあるppp Dialin
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].
このセクションでは、私たちはdialinネットワークアクセスのために[2]に提示されたフレームワークに関して承認モデルを提示します。 モデルに含まれているのは、ローミング[5]に必要であるマルチドメイン問題です。 ネットワークアクセス・プロトコルのための詳細な要件は[6]に提示されます。
2.1. Descriptive Model
2.1. 記述的モデル
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 dialinアプリケーションは[2]で議論するように牽引力の系列を使用します。 ローミングケースはまた、[2]で議論したローミング牽引力の系列を使用します。 この系列は以下を1図の用語に移動しながらdialinを使用するredrawnです。
Vollbrecht, et al. Informational [Page 4] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [4ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
+------+ +-------------------------+
| | | Home ISP |
| | | (User Home Organization)|
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | /|\ | |
| | +--------------+---+------+
| | | |
| | |3 |4
| | | |
| | +--------------+---+------+
| | | Visited ISP | | |
| | | | \|/ |
| User | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | /|\ | |
| | | |2 |5 |
| | | | \|/ |
| | 1 | +-------------------+ |
| |------+->| NAS (Service | |
| |<-----+--| Equipment) | |
| | 6 | +-------------------+ |
| | | (Service Provider) |
+------+ PPP +-------------------------+
+------+ +-------------------------+ | | | ホームISP| | | | (ユーザホーム組織)| | | | +-------------------+ | | | | | AAAサーバ| | | | | | | | | | | +-------------------+ | | | | /|\ | | | | +--------------+---+------+ | | | | | | |3 |4 | | | | | | +--------------+---+------+ | | | 訪問されたISP| | | | | | | \|/ | | ユーザ| | +-------------------+ | | | | | AAAサーバ| | | | | | | | | | | +-------------------+ | | | | /|\ | | | | | |2 |5 | | | | | \|/ | | | 1 | +-------------------+ | | |------+->| NAS、(サービス| | | | <、-、-、-、| --+--設備、)| | | | 6 | +-------------------+ | | | | (サービスプロバイダー) | +------+ ppp+-------------------------+
Fig. 1 -- Dialin Authorization
Based on Roaming Pull Sequence
図1--牽引力の系列に移動することに基づいたDialin承認
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
このモデルでは、Userは訪問されて(外国)のISP(一般的なモデルのService Provider)によって提供されたNetwork Access Server(NAS)に直通電話にかけます。 Userは、PPPフレーム(1)でカプセル化されるPAP、CHAP、またはEAPなどのプロトコルを使用することで認証されます。 Userがまだネットワークへのアクセスを得ていないので、その人はIPデータグラムをAAAサーバに送ることができません。ここに、UserはNAS(サービスEquipment)とコミュニケートできるだけです。 NASはRADIUS[8]を通したそれ自身のドメインか後継者AAAプロトコル(2)にNetwork Access Identifier(NAI)[7]をAAAサーバに含むUserの認証/承認要求を転送します。 訪問されたISPのAAAサーバは、NAIから分野を調べて、UserのホームドメインAAAサーバ(3)に要求を転送します。 ホームドメインAAAサーバは、ユーザを認証して、ローミング協定通りにアクセスを認可します。 ホームドメインAAAサーバはサービスパラメタを返すかもしれません。
Vollbrecht, et al. Informational [Page 5] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [5ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
(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).
NAS(ことによると付加の追加サービスパラメタ(5))にそれらを送る訪問されたISPのAAAサーバ(4)への(例えば、Idle-タイムアウト。) 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]で広げられるかもしれません。 例えば、別々のパスで専門化している形式の認証をサポートするのに異なったサーバを使用することでAuthenticationとAuthorizationをするかもしれません。 または、ローミングをよりよくサポートするために、ブローカーは訪問されたISPとホームISPの間に挿入されるかもしれません。 または、承認は、発信者番号などの他の識別子に基づいてサポートされて、PSTN(例えば、ANIを使用して、DNIS)から得られたIDと呼ばれるかもしれません。
2.2. Authorization Requirements
2.2. 承認要件
The following requirements are identified in [9] for authorizing PPP dialin service using roaming.
以下の要件はローミングを使用することでPPP dialinサービスを認可するための[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 ServerかPDP MUSTが同じ管理ドメインの中にあるかもしれない別のAAA ServerかPDPに要求を転送できることを意味して。
- The AAA protocol MUST allow for intermediate brokers to add their
own local Authorization information to a request or response.
- AAAプロトコルは、中間的ブローカーが地元のAuthorization情報を要求か応答に追加するのを許容しなければなりません。
- 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。 複数の認証、複数の承認
3. Mobile-IP
3. モバイルIP
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:
モバイルIPプロトコルは、IPサブネット[10]の向こう側にIPホストの移動性を管理するのに使用されます。 モバイルIP作業部会の中の最近の活動は提供するためにモバイルIPとAAAとの相互作用を定義しました:
Vollbrecht, et al. Informational [Page 6] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [6ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
- 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信頼モデルについて表現します。 このモデルでは、各ネットワークはモバイルノード(ミネソタ)と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 |
| | | | | |
+---------+ +---------+ +---------+
ブローカーAAA+--------+ | | | AAA| /=====| |=====\ // +--------+ \\外国//SA SA\\ホームAAA//\\AAA+--------+ +--------+ | | SA| | | AAA|======================| AAA| | | (ブローカーの代わりに) | | +--------+ +--------+ || || || SA|| SA|| || SA|| || || || || || +---------+ +---------+ +---------+ | | | | | | | ファ| | ハ| | ミネソタ| | | | | | | +---------+ +---------+ +---------+
Fig. 2 -- Mobile-IP AAA Trust Model
図2--モバイルIP AAA信頼はモデル化されます。
Vollbrecht, et al. Informational [Page 7] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [7ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
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ネットワークに関する例を提供します。 統合モバイルIP/AAA Networkでは、それぞれの移動性エージェントがそれ自体とそのローカルのAAAサーバとのセキュリティ協会を共有すると思われます。さらに、ホームとForeign AAAサーバはブローカーのAAAサーバとのセキュリティ協会を共有します。最後に、それぞれのモバイルノードがホームAAA Serverとの信頼関係を共有すると思われます。
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 |
+--------+
訪問されたアクセスのホームIPプロバイダーネットワークネットワークブローカーネットワーク+--------+ +--------+ +--------+ | | | | | | | AAA|------| AAA|------| AAA| | | | | | | +--------+ +--------+ +--------+ | | | | AAA| | AAA| | | | +---------+ +---------+ | | | | | ファ| | ハ| | | | | +---------+ +---------+ | | 訪問されたアクセスホームネットワーク| プロバイダーのネットワークの私設のネットワークモバイルです。| -ホームプロバイダーIP| -ホームISP| +--------+ | モバイル| | ノード| +--------+
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:
この例では、モバイルNodeは外国ネットワークの中に現れて、Foreignエージェントに登録証明書を発行します。 Foreignエージェントがホームのエージェントとの少しのセキュリティ仲間も共有しないので、それはローカルのAAAサーバにAAA要求を送ります。(それは、認証情報とモバイルIP登録要求を含んでいます)。 モバイルNodeは2つの理由でホームAAA Serverと共に直接伝達できません:
Vollbrecht, et al. Informational [Page 8] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [8ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
- 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.
- それはネットワークに近づく手段を持っていません。 登録要求は、ネットワークへのアクセスを要求するためにモバイルNodeによって送られます。 - モバイルNodeは、IPアドレスを持たないで、1つがホームプロバイダーによってそれに割り当てられるよう要求しているかもしれません。
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.
Foreign AAA Serverは、モバイルNodeによって提供されたNetwork Access Identifier[7]の使用で要望が局所的に応じることができるかどうか決定するでしょう。 NAIには、 user@realm の形式があります、そして、AAA ServerはモバイルNodeのホームAAA Serverを特定するのにNAIの分野の部分を使用します。Foreign AAA ServerがモバイルNodeのホームAAA Serverとのどんなセキュリティ協会も共有しないなら、それは要求をブローカーに転送するかもしれません。 ブローカーにホームネットワークとの関係があるなら、それは要求を転送できます。さもなければ、Foreign AAA Serverは失敗した応答に送り返されます。
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:
ホームAAA ServerがAAA Requestを受けるとき、それは、ユーザを認証して、承認フェーズを始めます。 承認フェーズは以下の世代を含んでいます。
- 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]
- すべてのMobilityエージェントの中で分配されるべきダイナミックなSessionキーズ--ホームのエージェントの任意のDynamic課題--ホームAddress(ホームのエージェントがこれができたことに注意する)の任意のDynamic課題。 - モバイルNodeのためのQOSパラメタの任意のAssignment[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.
承認がいったん完全になると、ホームAAA Serverは求められていないAAA要求をホームのエージェントに出します。(そのエージェントは、ホームAAAサーバによって生成された承認情報と同様にオリジナルのAAA要求に情報を含んでいます)。ホームのエージェントは、AAA要求からRegistration Requestを検索して、それを処理して、次に、AAA応答におけるホームAAAサーバが送り返されるRegistration Replyを生成します。 ブローカーを通してForeign AAAサーバと、そして、最終的なForeignエージェントにメッセージを転送します。
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サーバは承認情報に基づくセッション州の情報を保守します。 モバイルNodeが外国ドメインの中の別のForeignエージェントに移行するなら、すぐに、すぐに前のForeignエージェントに支給されたキーを返すために外国AAAサーバに要求できます。 マイクロ移動性がかかわって、滑らかなハンドオフを可能にすると、これはインターネットを通した追加周遊旅行を最小にします。
Vollbrecht, et al. Informational [Page 9] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [9ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
3.1. Relationship to the Framework
3.1. フレームワークとの関係
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.
モバイルIPは[2]で説明されたローミング牽引力のモデルを使用します。 モバイルNodeはUserです。 Foreign NetworkはService EquipmentとしてのForeignエージェントがいるService Providerです。 ホームNetworkはUserホームOrganizationです。 UserホームOrganizationがAAA Serverだけではなく、ホームのエージェントも手術することに注意してください。 また、ブローカーがService ProviderとUserホームOrganizationの間に挿入されたことに注意してください。
3.2. Minimized Internet Traversal
3.2. 最小にされたインターネット縦断
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相互作用が基本認証、承認、およびForeignエージェントから直接ホームのエージェントに送られるRegistration流動のために実行されるのが、可能だったでしょうが、主要なモバイルIP AAA要件の1つはインターネットTraversalsを最小にすることです。 AAAメッセージにRegistration RequestとRepliesを含んでいるのは、ただ一つの縦断がユーザを認証して、承認を実行して、Registration Requestを処理するのを許容します。 この流線型のアプローチが、ネットワークへのワイヤレス(セル)のデバイスアクセスを得るのにかかわる潜在を最小にするのに必要です。 新しい登録証明書は現在のセルラー・ネットワークが提供するものほど接続時間を増強するべきではありません。
3.3. Key Distribution
3.3. 主要な分配
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.
管理ドメインの向こう側にワイヤレスのデータ・アクセスのスケーリングを許すために、協会が必要としたセキュリティを最小にするのが必要です。 これは、それぞれのForeignエージェントがインターネットのそれぞれのホームのエージェントとのセキュリティ仲間を共有しないことを意味します。 Mobilityエージェントは地元のAAAサーバとの他のAAAサーバとのセキュリティ協会が順番に共有されるセキュリティ協会を共有します。 一方、ブローカーのRoaming Operations(roamops)作業部会によって定義される使用で、プロバイダーによって確立された関係の数が減少するのを許容することによって、そのようなサービスは比例します。
After a Mobile Node is authenticated, the authorization phase includes the generation of Sessions Keys. Specifically, three keys are generated:
モバイルNodeが認証された後に、承認フェーズはセッションズキーズの世代を含んでいます。 明確に、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--Foreignエージェントとホームのエージェントの間の共有されているために主要なモバイルNodeとForeignエージェント(k3)の間の共有されているために主要なモバイルNodeとホームのエージェント(k2)の間で共有されるべきキー
Vollbrecht, et al. Informational [Page 10] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [10ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
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).
各KeyはAAAプロトコル(Foreignとホームのエージェントのための)を通してモバイルNodeのためのモバイルIPを通してそれぞれの移動性デバイスに伝播されます(モバイルNodeが直接AAAサーバに接続しないので)。
Figure 4 depicts the new security associations used for Mobile-IP message integrity using the keys derived by the AAA server.
図4はモバイルIPメッセージの保全にAAAサーバによって引き出されたキーを使用することで使用される新しいセキュリティ協会について表現します。
+--------+ +--------+
| | k3 | |
| FA |======================| HA |
| | | |
+--------+ +--------+
\\ //
\\ k2 k1 //
\\ +--------+ //
\\ | | //
\=====| MN |=====/
| |
+--------+
+--------+ +--------+ | | k3| | | ファ|======================| ハ| | | | | +--------+ +--------+ \\//\\k2 k1//\\+--------+ // \\ | | // \=====| ミネソタ|=====/ | | +--------+
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インフラストラクチャを使用しなければなりませんでした後)。
3.4. Mobile-IP Authorization Requirements
3.4. モバイルIP承認要件
To summarize, Mobile-IP has the following authorization requirements:
まとめるためにモバイルIPには、以下の承認要件があります:
1. Mobile-IP requires an AAA protocol that makes use of the pull
model.
1. モバイル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. モバイル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. 承認はResource Managementを含んでいます。 これで、情報などを合わせて、AAAサーバはモバイルノードの現在の位置のスナップを維持できます。
Vollbrecht, et al. Informational [Page 11] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [11ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
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プロトコルは認証と承認のための単発旅行を考慮するべきです。
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. 承認データに伴う特定のかぎ管理データをモバイルIPに通過するのは可能であるに違いありません。 これで、AAAサーバはKey Distributionセンター(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のクライアントなどのように。
4. Bandwidth Broker
4. 帯域幅ブローカー
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掲示板Advisory Councilの中で議論するようにBandwidth Brokerアーキテクチャから得られた承認局面について説明します。 私たちは契約関係を特定して、関係を信じるのに承認モデル概念を使用します、そして、可能な交換処理を提示します。 私たちは私たちの建築モデルからBandwidth Brokersのための1セットの承認要件を引き出すつもりです。 インターネット2Qbone掲示板Advisory Councilは2層の承認概念に基づく単一の、そして、マルチドメインの実装について研究します。 3層のモデルは今後の活動項目がみなされて、したがって、この記述のいずれの一部もみなされません。 以下で2Bandwidth Brokerが扱うインターネットに関する情報とその概念を見つけることができます。
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] どれがInternet2 Qbone掲示板Advisory Councilの処理中の作業であるかに基づいています。
Vollbrecht, et al. Informational [Page 12] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [12ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
4.1. Model Description
4.1. モデル記述
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.2. Components of the Two-Tier Model for Bandwidth Brokerage
4.2. 帯域幅仲買業のための2層のモデルの部品
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層のモデルはService Equipmentを制御するUserとService Providerを認識します。
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).
- Service User(ユーザ)--選択された目的地とそれ自体の間の定量化可能な量のリソースの配分を要求することによってQoSのあるレベルを使用しても構わないと思っている人かプロセス。 帯域幅ブローカー用語で、UserはResource Allocation Request(RAR)を生成することができるService Userと呼ばれます。
- 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.
- Bandwidth Broker(サービスProvider)--特定されたソースと目的地の間の帯域幅リソースの一定金額の配分を認可する機能は1セットの方針を基礎づけました。 このような関係においては私たちはこの機能をBandwidth Brokerと呼びます。 Bandwidth Brokerはそれが制御するネットワークドメインの中でリソースの有用性を管理できます。
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.
以下に注意してください。 UserホームOrganizationにかかわる3層のモデルは[13]で見分けられます、そして、しかしながら、開発を今後の研究に発たれます、そして、したがって、本書ではそれについて議論しません。
4.3. Identification of Contractual Relationships
4.3. 契約上の関係の識別
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.
帯域幅を得る承認は契約上の関係に基づいています。 両方の単一の、そして、マルチドメインの場合では、現在のBandwidth Brokerモデルは、Userにはそれが関連しているサービスドメインとの契約上の関係がいつもあると仮定します。
Vollbrecht, et al. Informational [Page 13] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [13ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
4.3.1. Single-Domain Case
4.3.1. 単一領域ケース
In the single-domain case, the User has a contract with a single Service Provider in a single service domain.
単一領域場合では、Userはただ一つのサービスドメインに独身のService Providerとの契約を持っています。
+-------------+
| |
| +---------+ |
| |Bandwidth| |
+-------+ | |Broker | |
| | | | | |
|Service| | +---------+ |
|User |=========| |
| | | +---------+ |
| | | | Network | |
+-------+ | | Routing | |
| | Devices | |
| +---------+ |
| Autonomous |
| Service |
| Domain |
+-------------+
==== contractual
relationship
+-------------+ | | | +---------+ | | |帯域幅| | +-------+ | |ブローカー| | | | | | | | |サービス| | +---------+ | |ユーザ|=========| | | | | +---------+ | | | | | ネットワーク| | +-------+ | | ルート設定| | | | デバイス| | | +---------+ | | 自治| | サービス| | ドメイン| +-------------+ ==== 契約上の関係
Fig. 5 -- Two-Tier Single Domain Contractual Relationships
図5--2層の単一領域契約上の関係
Vollbrecht, et al. Informational [Page 14] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [14ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
4.3.2. Multi-Domain Case
4.3.2. マルチドメインケース
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.
マルチドメイン場合では、Userは独身のService Providerとの契約を持っています。 このService Providerには、隣接しているService Providersとの契約があります。 独立している自治のネットワークが互いと共に契約法を確立するとき、このモデルは使用されています。
+-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |Bandwidth| | | |Bandwidth| |
+-------+ | |Broker | | | |Broker | |
| | | | | | | | | |
|Service| | +---------+ | | +---------+ |
|User |=========| |========| |
| | | +---------+ | | +---------+ |
| | | | Network | | | | Network | |
+-------+ | | Routing | | | | Routing | |
| | Devices | | | | Devices | |
| +---------+ | | +---------+ |
| Autonomous | | Autonomous |
| Service | | Service |
| Domain A | | Domain B |
+-------------+ +-------------+
+-------------+ +-------------+ | | | | | +---------+ | | +---------+ | | |帯域幅| | | |帯域幅| | +-------+ | |ブローカー| | | |ブローカー| | | | | | | | | | | | |サービス| | +---------+ | | +---------+ | |ユーザ|=========| |========| | | | | +---------+ | | +---------+ | | | | | ネットワーク| | | | ネットワーク| | +-------+ | | ルート設定| | | | ルート設定| | | | デバイス| | | | デバイス| | | +---------+ | | +---------+ | | 自治| | 自治| | サービス| | サービス| | ドメインA| | ドメインB| +-------------+ +-------------+
==== contractual
relationship
==== 契約上の関係
Fig. 6 -- Two-Tier Multi-Domain Contractual Relationships
図6--2層のマルチドメイン契約上の関係
Vollbrecht, et al. Informational [Page 15] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [15ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
4.4. Identification of Trust Relationships
4.4. 信頼関係の識別
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.
信頼(認証されてことによると安全なコミュニケーションを容易にするのに必要である)がどう実装されるかから契約上の関係は独立しているかもしれません。 信じられた関係を作成するために、Bandwidth Broker環境におけるいくつかの選択肢があります。 数字7と8は2層のBandwidth Brokerモデルでオプションである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 |
+-------------+ +-------------+
+-------------+ +-------------+ | | | | | +---------+ | | +---------+ | | |帯域幅| | | |帯域幅| | +-------+ | |ブローカー| | | |ブローカー| | | ○ ***********O O************O| | |サービス| | +----O----+ | | +----O----+ | |ユーザ|=========| * |========| * | | | | +----0----+ | | +----O----+ | | | | |ネットワーク| | | |ネットワーク| | +-------+ | |ルート設定| | | |ルート設定| | | |デバイス| | | |デバイス| | | +---------+ | | +---------+ | | 自治| | 自治| | サービス| | サービス| | ドメインA| | ドメインB| +-------------+ +-------------+
==== contractual relationship
O**O trust relationship
==== 契約上の関係O**O信頼関係
Fig. 7 -- Two-Tier Multi-Domain Trust Relationships, alt 1
図7--2層のMulti-ドメインTrust Relationships、alt1
Vollbrecht, et al. Informational [Page 16] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [16ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
+-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |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 |
+-------------+ +-------------+
+-------------+ +-------------+ | | | | | +---------+ | | +---------+ | | |帯域幅| | | |帯域幅| | +-------+ | |ブローカー| | | |ブローカー| | | | | | | | | | | | |サービス| | +----O----+ | | +----O----+ | |ユーザ|=========| * |========| * | | | | +----O----+ | | +----O----+ | | O***********OネットワークO************Oネットワーク| | +-------+ | | ルート設定| | | | ルート設定| | | | デバイス| | | | デバイス| | | +---------+ | | +---------+ | | 自治| | 自治| | サービス| | サービス| | ドメインA| | ドメインB| +-------------+ +-------------+
==== contractual relationship
O**O trust relationship
==== 契約上の関係O**O信頼関係
Fig. 8 -- Two-Tier Multi-Domain Trust Relationships, alt 2
図8--2層のMulti-ドメインTrust Relationships、alt2
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]はこの質問に関して詳細を推薦しませんが、ドキュメントは信頼関係の必要性を認識します。 第1代モデルでは、何らかのフォームの認証方法に基づく信頼関係はUserとBandwidth Brokerの間と、そして、Bandwidth Brokersの中で作成されます。 第2代モデルに、信頼関係は物理的なルータポートかMACアドレスがどのユーザにつなげられる配線クロゼットと知識で確立されるかもしれません。(モデルは企業網のいくらかの人気を楽しみます)。 ルータ帯域幅Broker関係はある他の物理的か認証方法か安全なチャンネルによって確立されるかもしれません。
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.
Certificate Authorityの(カリフォルニア)ベースの信頼関係は9が中で計算するのが示されます。 この図では、カリフォルニアは公開鍵証明書に署名します。(次に、暗号化メッセージ交換にかかわるすべてによって信じられる公開鍵を使用することで証明書を使用できます)。 第一歩として、それぞれのかかわったパーティーは、信頼ドメインを接合できるようにカリフォルニアとともに記名しなければなりません。 Router-帯域幅Broker関係は前の2つの数字で説明されるように確立されるかもしれません。 この種類のモデルでのおもしろい観測はドメインBの帯域幅ブローカーが情報を読むことができるので(終わりから終わりへのセキュリティを使用して)ドメインAの帯域幅ブローカーを通してBB1なしで情報をユーザに発送するかもしれないということです。 このモデルはカリフォルニア構造のような木を通してかみ合っている信頼関係を作成します。
Vollbrecht, et al. Informational [Page 17] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [17ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
+-------------------+
| 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 |
+-------------+ +-------------+
+-------------------+ | 証明書| ....................| 権威| : ..| |.. : : +-------------------+ : : : : : : : : ***************:*********************** : : * +---:---------+ +---*--:------+ : * | : | | * : | : * | +-:-------+ | | +O--、:----+ | : * | |C| | | | C| | +---:--○ +| |帯域幅| | | |帯域幅| | | C、O***********OブローカーO************Oブローカー| | |サービス| | +----O----+ | | +----O----+ | |ユーザ|=========| * |========| * | | | | +----0----+ | | +----O----+ | | | | |ネットワーク| | | |ネットワーク| | +-------+ | |ルート設定| | | |ルート設定| | | |デバイス| | | |デバイス| | | +---------+ | | +---------+ | | 自治| | 自治| | サービス| | サービス| | ドメインA| | ドメインB| +-------------+ +-------------+
==== contractual relationship
O**O trust relationship
{C}. certification process
==== C証明が処理する契約上の関係O**O信頼関係
Fig. 9 -- Two-Tier Multi-Domain Trust Relationships, alt 3
図9--2層のMulti-ドメインTrust Relationships、alt3
4.5. Communication Models and Trust Relationships
4.5. コミュニケーションモデルと信頼関係
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.
Bandwidth Brokerコミュニケーションモデルについて説明するとき、コンポーネントの間の信頼関係がかかわったコンポーネントの安全で認証されたコミュニケーションを確実にしなければならないと認めるのは重要です。 2Qbone Bandwidth Brokerが扱うインターネットが少しの特定の信頼関連モデルも推薦しないとき、私たちは[13]と同じ仮定をします。 理論上、信頼モデルとコミュニケーションモデルが独立している場合がある、しかしながら、コミュニケーション効率は最も論理的なアプローチを決定するでしょう。
Vollbrecht, et al. Informational [Page 18] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [18ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
4.6. Bandwidth Broker Communication Models
4.6. 帯域幅ブローカーコミュニケーションモデル
4.6.1. Concepts
4.6.1. 概念
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.
現在のインターネット2Qbone Bandwidth Broker議論はそのドメインかRARが上流のBandwidth Brokersで隣接しているドメインから生成したユーザからのResource Allocation Requests(RARのもの)がものである2層のモデルについて説明します。そこでは、Bandwidth Brokerが受け入れます。 各Bandwidth Brokerは1つのサービスドメインを管理して、次に、要求を光栄に思うことができるかどうか決める方針に基づく承認を提供するでしょう。
4.6.1.1. Intra-Domain Authorization
4.6.1.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.
イントラドメインコミュニケーションのための入場AuthorizationかConnection Admission Control(CAC)が、どんなドメインの中でリソースの有用性を決定するのに、適切なメソッドも使用することで実行されます。 一般にBandwidth Brokerはあるレベルのサービスにサービスドメインを構成します。 RARのものは、次に、方針ベースの決定を使用することで設備されます。
4.6.1.2. Inter-Domain Authorization
4.6.1.2. 相互ドメイン承認
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.
サービスLevel Specifications(SLSのもの)は取り扱い相互ドメイン帯域幅承認要求の基礎を提供します。 Bandwidth Brokerはネットワーク要素の州と接続の状態の両方を隣接しているネットワークにモニターします。 SLSのものはAutonomous Service Domainsの間で確立されたSLAに関する翻訳です。 各Bandwidth Brokerがそれ自体を初期化するので、それは既存のSLSのものを意識しています。 SLSのものは単方向の意味に設立されます。 2SLSのものは双方向の接続を治めなければなりません。 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.
Bandwidth Brokerは、特定のRARがプレ確立したSLSに収まることを決定しながら政策決定を適用することによって、相互ドメインRARを尊敬するかもしれません。 うまくいくと、Bandwidth Brokerは帯域幅の用法を認可するでしょう。 失敗しているなら、川下のBandwidth BrokerとSLSを再交渉した後に、Bandwidth Brokerは要求を否定するか、または要求を承認するかもしれません。
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].
別々のPolicyマネージャはCAC決定にかかわるかもしれません。 2Qbone Bandwidth Broker議論がCAC使用を提供するために、Bandwidth BrokersとPolicyマネージャが働いている理想的な環境を一緒に、認識するインターネットは方針サービス[13]を統合しました。
Vollbrecht, et al. Informational [Page 19] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [19ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
4.6.2. Bandwidth Broker Work Phases
4.6.2. 帯域幅ブローカー仕事フェーズ
The Internet 2 Qbone Bandwidth Broker discussion proposes development of the Bandwidth Broker model in several phases:
インターネット2Qbone Bandwidth Broker議論はいくつかのフェーズにおける、Bandwidth Brokerモデルの進化を提案します:
- 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のものは、手話教授法(ファックス、電子メール)を使用することであらかじめ設立されます。
- 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の複数のわたっているドメインが経路に沿った1Bandwidth Brokersから得られた情報に基づいて認可されます。
- Phase 2: Dynamic SLS admission. Bandwidth Brokers can dynamically
set up new SLS's.
- フェーズ2: ダイナミックなSLS入場。 帯域幅Brokersはダイナミックに新しい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.
ローカルの入場ケースは扱われますが、2Qbone Bandwidth Brokerが扱う現在のインターネットは現在、フェーズ0か1で特定されるように個々のBandwidth Brokersが共同利用するのを許容するためにマルチドメイン問題を解決するのに関係があります。
4.6.3. Inter-Domain Signaling
4.6.3. 相互ドメインシグナリング
4.6.3.1. Phase 0
4.6.3.1. フェーズ0
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実装では、Bandwidth Brokersの間のどんな電子シグナリングも実行されません、そして、SLS交渉はネットワーク・オペレータによって手動(メール電話など)で実行されるでしょう。 RARはドメインの中で扱われるだけであり、Userかイングレスルータから発するかもしれません。
4.6.3.2. Phase 1
4.6.3.2. フェーズ1
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.
ここで、川下のBandwidth Brokersから得られた情報でCAC決定をします。 この情報は次のホップBandwidth BrokerかすべてのBandwidth Brokersから川下に目的地に来ることができました。
Two fundamental signaling approaches between Bandwidth Brokers have been identified for the Informed Admission case. These are illustrated in figure 10.
Bandwidth Brokersの間の2つの基本的なシグナリングアプローチがInformed Admissionケースのために特定されました。 これらは図10で例証されます。
Vollbrecht, et al. Informational [Page 20] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [20ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
+-------+ +-------+ +-------+ +-------+ | | | | | | | | | |RAR | | 1 | | 2 | | | User |-------->| |-------->| |-------->| | | | RAA | BB1 | 4 | BB2 | 3 | BB3 | | |<--------| |<--------| |<--------| | | | | | | | | | | | | | | | | | +-------+ +-------+ +-------+ +-------+
+-------+ +-------+ +-------+ +-------+ | | | | | | | | | |RAR| | 1 | | 2 | | | ユーザ|、-、-、-、-、-、-、--、>| |、-、-、-、-、-、-、--、>| |、-、-、-、-、-、-、--、>|、|、|、| 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 | | | |<--------| |<--------| |<--------| | +-------+ +-------+ +-------+ +-------+
+-------+ +-------+ +-------+ +-------+ | | | | | | | | | |RAR| | 1 | | 3 | | | ユーザ|、-、-、-、-、-、-、--、>| |、-、-、-、-、-、-、--、>| |、-、-、-、-、-、-、--、>|、|、|、| 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.
- Endシグナリングの終わり。 UserからBB1までのRARをBB2(1)に送ります。 BB2はBB3(2)に要求を転送するでしょう。 BB3が要求の目的地であるなら、BB3は要求を認可して、BB2(3)に答えるでしょう。 次に、BB2はBB1(4)に答えるでしょう、そして、BB1は承認を完成するために、Resource Allocation Answer(RAA)をUserに送り返すでしょう。
- 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をUserに送り返すでしょう。 承認がBB2が次に次の掲示板への要求、BB3(3)を進めるのを確信していたなら。 BB3は要求を認可して、BB2(4)に応じます。 応答が否定的(5)であるなら、BB2はそれが以前にBB1(6)に発行した承認を取り消すでしょう、そして、これはBB1からユーザ(7)までのキャンセルをもたらすでしょう。 この場合、RAA承認は7時までに取り消されるまで有効です。
Vollbrecht, et al. Informational [Page 21] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [21ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
4.6.4. Bandwidth Broker Communication Architecture
4.6.4. 帯域幅ブローカー通信アーキテクチャ
Figure 11 shows components of the discussed Bandwidth Broker architecture with its interfaces.
図11はインタフェースで議論されたBandwidth Brokerアーキテクチャの成分を示しています。
- An intra-domain interface allows communication with all the
service components within the network that the Bandwidth Broker
controls.
- イントラドメイン界面はBandwidth Brokerが制御するネットワークの中のすべてのサービスコンポーネントとのコミュニケーションを許容します。
- An inter-domain interface allows communication between Bandwidth
Brokers of different autonomous networks.
- 相互ドメイン界面は異なった自治のネットワークのBandwidth Brokersのコミュニケーションを許容します。
- A user/application interface allows the Bandwidth Broker to be
managed manually. Requests can be sent from the User or a host
application.
- ユーザ/アプリケーション・インターフェースは、Bandwidth Brokerが手動で管理されるのを許容します。 Userかホストアプリケーションから要求を送ることができます。
- 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.
- 経路指定テーブルインタフェースで、Bandwidth Brokerはネットワーク形態を理解できます。
- An NMS interface allows coordination of network provisioning and
monitoring.
- NMSインタフェースはネットワークの食糧を供給するのとモニターのコーディネートを許します。
Vollbrecht, et al. Informational [Page 22] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [22ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
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)
隣接している掲示板<。---------------------------掲示板に隣接した>。| +に対して------------------------------+ | | 相互ドメイン| | | -------------- ------| アプリケーション| | 午後| サーバ、\| |iface| \ |------- ---------+ ------| ->| ユーザ/| | 簡単| ------| ユーザ/ホスト-->| 装置| | 方針| | NMS| ->| iface| | サービス| |iface| / |------- ---------+ ------| ネットワーク/| | オペレータ| ------- ------- | | | データ| |ルーティング| | | | 店| |インフォメーション| | | | | | | | | ------- ------- | | | | ---------------- | | | イントラドメイン| | +------------------------------+ ^ | 縁のルータ<。--------------------------->縁のルータ(s)
Fig. 11 -- Bandwidth Broker Architecture
図11--帯域幅ブローカーアーキテクチャ
4.6.5. Two-Tier Inter-Domain Bandwidth Broker Communication Model
4.6.5. 2層の相互ドメイン帯域幅ブローカーコミュニケーションモデル
4.6.5.1. Session Initialization
4.6.5.1. セッション初期設定
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).
Bandwidth Brokersが2つの隣接しているドメインの間のサービスを構成できる前に、それらは、関係を設立して、初期化しなければなりません。 どんな認証も使用されていません。 したがって、どんな信頼関係も暗黙です。 初期化の一部がトポロジー情報(隣接しているBandwidth Brokersのリスト)の交換です。
4.6.5.2. Service Setup
4.6.5.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.
最初に、同意された双方のサービスレベルに関してBandwidth Brokerを構成しなければなりません。 各ドメインで特定のレベルの食糧を供給されたサービスに割り当てられたすべてのリソースを予約しなければなりません。
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
Service Setup Request(SSR)を生成して(オペレータによる要求の上、または、システムの始動で)、川下のBandwidth Brokerに送ります。 川下のBandwidth Brokerはチェックするでしょう。
Vollbrecht, et al. Informational [Page 23] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [23ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
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.
それ自身のサービスがある一貫性は、Setup Answerメッセージ(SA)協定で仕様を平らにして、応じます。 この交換処理は、プレ確立したサービス承認レベルを確認して、特定します。
4.6.5.3. Service Cancellation
4.6.5.3. サービスキャンセル
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.
Service Cancellation(サウスカロライナ)メッセージはサービス承認を取り消すかもしれません。 このメッセージはオペレータか有効期限までに開始されるかもしれません。 Cancellation Answer(カリフォルニア)を返します。
4.6.5.4. Service Renegotiation
4.6.5.4. サービスRenegotiation
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.
(任意)のサービス-Renegotiationメッセージ(SR)で、Bandwidth Brokerは既存のサービスを再交渉できるかもしれません。 オペレータかそれとも自動的に、ある敷居にいつ達しているか時までにこのメッセージは開始されるかもしれません。 Renegotiationsはプレ確立した承認のマージンの中で起こります。
4.6.5.5. Resource Allocation Request and Resource Allocation Answer
4.6.5.5. 資源配分要求と資源配分に答えます。
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はUserを代表して要求されたレベルのサービスを割り当てます、そして、利用可能であるときに、それはあるUserの入場をサービスに決めるでしょう。 Bandwidth Brokerはイントラドメインか相互ドメイン界面を通してRARを受けるかもしれません。 RARはService SetUp Identification(SSU_ID)について言及しなければなりません。(Service SetUp Identificationはある承認に要求を縛ります)。 Resource Allocation Answer(RAA)が要求を確認するか、拒絶します、またはそれは「進行中」の状態を示すかもしれません。
4.6.5.6. Session Maintenance
4.6.5.6. セッションメインテナンス
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.
あるレベルのセッションメインテナンスが、互いを意識しているようにBandwidth Brokersを保つのに必要です。 これは、時間アウトを使用することで実装されて、メッセージを生かさなければなりません。 これは、Bandwidth Brokersが、他のBandwidth Brokersがいつ見えなくなるかに気付くのを助けるでしょう。
4.6.5.7. Intra-domain Interface Protocol
4.6.5.7. イントラドメイン界面プロトコル
The Intra-domain interface protocol used between a Bandwidth Broker and the routers it controls may be COPS, SNMP, or Telnet Command Line Interface.
Bandwidth Brokerとそれが制御するルータの間で使用されるIntra-ドメイン界面プロトコルは、COPS、SNMP、またはTelnet Command線Interfaceであるかもしれません。
4.7. Requirements
4.7. 要件
From the above descriptions we derive the following requirements.
上の記述から、私たちは以下の要件を引き出します。
Vollbrecht, et al. Informational [Page 24] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [24ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
- 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.
- UserからService Providerまでどんな要求もすることができる前にAuthorizationメカニズムは、信頼関係が確立されるのを必要とするかもしれません。 現在の、信頼関係設立は内在しています。
- 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.
- 条項にBandwidth Brokerの後の州が再初期化する承認の再構成を許させなければなりません。
5. Internet Printing
5. インターネット印刷
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.
インターネットPrintingプロトコル(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印刷で、ユーザは、特定のファイルを印刷するよう印刷サービスに要求できます。 ユーザはプリンタの特定のファイルを印刷するという(または、プリンタのグループの1つ)要求を作成します。 特徴は要求がファイル内容ではなく、ファイル名だけを含んでいるということです。 そして、印刷サービスは印刷の前でファイルサーバーからファイルを読まなければなりません。 ファイルサーバーとプリント・サーバの両方が要求を認可しなければなりません。 いったん開始すると、ユーザの介入なしで印刷するでしょう。 直接プリンタへのユーザを通してというよりむしろ印刷サービスにすなわち、ファイルを送るでしょう。
Vollbrecht, et al. Informational [Page 25] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [25ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
5.1. Trust Relationships
5.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.
仮定はPrinterとFile Serverが異なった組織によって所有されて、運用されるかもしれないということです。 どう「協定」をセットアップできるように2つのモデルが、あるように見えるか。
1. User has agreement with Print Server; Print Server has agreement
with File Server.
1. ユーザには、Print Serverとの協定があります。 印刷Serverには、File Serverとの協定があります。
2. User has agreements with both File and Print Server directly.
2. ユーザには、FileとPrint Serverの両方との協定が直接あります。
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では、ユーザはPrint Service AAA Serverとの信頼関係を持っています。Printerは要求をFile Serverに転送します。File Serverは、Printerを認可して、ファイルへのアクセスがPrinterに許されているかどうか決定します。 いくつかのケースがファイルへのアクセスがそれ自身のところでPrint Serverに許されるかもしれないところにあるかもしれない間、それに注意してください、(恐らくいくつか、「公衆はファイルする」か、または缶はある「安全な」プリンタに印刷されるだけです)、通常、ファイルがプリンタではなく、ユーザに関連しているのは、事実です。 印刷サービスを攻撃の魅力的なポイントにする傾向があるとき、これは良い「ジェネリック」モデルではありません。
+------+ +----------------------+
| | | File Service |----+
| | | AAA Server |<-+ |
| | +----------------------+ | |
| | | | | |
| | | File Server | | |
| | | | | |
| User | +----------------------+ | |
| | | |
| | | |
| | | |
| | +----------------------+ | |
| |------>| Print Service |--+ |
| |<------| AAA Server |<---+
| | +----------------------+
| | | Print Server |
| | | and Printer |
+------+ +----------------------+
+------+ +----------------------+ | | | ファイルサービス|----+ | | | AAAサーバ| <、-+ | | | +----------------------+ | | | | | | | | | | | ファイルサーバー| | | | | | | | | | ユーザ| +----------------------+ | | | | | | | | | | | | | | | | +----------------------+ | | | |、-、-、-、-、--、>| サービスを印刷してください。|--+ | | | <、-、-、-、-、--、| AAAサーバ| <、-、--+ | | +----------------------+ | | | プリント・サーバ| | | | そして、プリンタ| +------+ +----------------------+
Fig. 12 -- Case 1
User authorizes with Print Service.
Printer authorizes with File Service.
図12--UserがPrint Serviceと共に認可する1をケースに入れてください。 プリンタはFile Serviceと共に認可します。
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
場合2では、ユーザは、それぞれがUserに適切なサービスについて確かめることができるように、ファイルと印刷サービスの両方との信頼関係を持たなければなりません。 この場合、Userは最初に、File Service AAA ServerとPrintのために承認を可能にするという要求に連絡します。
Vollbrecht, et al. Informational [Page 26] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [26ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
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.
アクセスにファイルを調整してください。 これはいろいろ完了しているかもしれません、例えば、File Service AAA Serverがアクセサリーを可能にするためにFile Serverに寄贈できる(Print Serviceを通して)Userにトークンを返すかもしれません。
+------+ +----------------------+
| |------>| File Service |
| |<------| AAA Server |
| | +----------------------+
| |
| | +----------------------+
| | | File Server |
| User | +----------------------+
| | /|\ |
| | | |
| | | \|/
| | +----------------------+
| |------>| Print Service |
| |<------| AAA Server |
| | +----------------------+
| | | Print Server |
| | | and Printer |
+------+ +----------------------+
+------+ +----------------------+ | |、-、-、-、-、--、>| ファイルサービス| | | <、-、-、-、-、--、| AAAサーバ| | | +----------------------+ | | | | +----------------------+ | | | ファイルサーバー| | ユーザ| +----------------------+ | | /|\ | | | | | | | | \|/ | | +----------------------+ | |、-、-、-、-、--、>| サービスを印刷してください。| | | <、-、-、-、-、--、| AAAサーバ| | | +----------------------+ | | | プリント・サーバ| | | | そして、プリンタ| +------+ +----------------------+
Fig. 13 -- Case 2
User authorizes File and Print Service.
Must create binding for session between
Print Service and File Service.
図13--ケース2UserはFileとPrint Serviceを認可します。 Print ServiceとFile Serviceとのセッションのために拘束力があるように作成しなければなりません。
5.2. Use of Attribute Certificates in Print-by-Reference
5.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]で議論するように属性証明書の使用の好例を提供します。 ケース2について説明するなら、上では、属性証明書(ACs)に関して私たちが14が中で計算するのをダイヤグラムを示させます。
Vollbrecht, et al. Informational [Page 27] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [27ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
+------+ +----------------------+
| |------>| 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 |<---+
+------+ +----------------------+
+------+ +----------------------+ | |、-、-、-、-、--、>| ファイルサービス| | | <、-、-、-、-、--、| AAAサーバ| | |西暦+を手に入れてください。----------------------+ | | | | +----------------------+ | | | ファイルサーバー|----+ | | | | <、-+ | | ユーザ| +----------------------+ | | | | | | | | +---西暦を通過するのを認可してください。| | <、-、--セッションを作成してください。| | | | | 西暦を使用します。| | +に対して----------------------+ | | | |、-、-、-、-、--、>| サービスを印刷してください。| | | | | <、-、-、-、-、--、| AAAサーバ| | | | | +----------------------+ | | | | | プリント・サーバ|--+ | | | | そして、プリンタ| <、-、--+ +------+ +----------------------+
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.
この場合、UserはFile Service AAA Serverによって署名されるFile ServiceのAAA Serverから西暦を得て、西暦の所有者がすることができることについて説明する1セットの属性を含みます。 Userは次に、Print Serviceと共にAAA Serverを認可して、承認要求で西暦を通過します。 西暦をそれに通過して、PrinterはFile Serverとのセッションを確立します。 それがFile Service AAA Serverによって署名されるのでFile Serverが西暦を信じる、許容、(禁じる、)、セッション。
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.
また、西暦にUserが作成されて、署名して、Print ServerからFile Serverまで通過できたことに注意するのはおもしろいです。File Serverは、Userの署名を認識できる必要があるでしょう。 さらに別の可能性はPrint Service AAA Serverが単にUserを認証して、次に、File Service AAA Serverから西暦を要求できたということです。
5.3. IPP and the Authorization Descriptive Model
5.3. IPPと承認記述的モデル
The descriptive model presented in [2] includes four basic elements: User, User Home Organization, Service Provider AAA Server, and Service Equipment.
[2]に提示された記述的モデルは4個の基本要素を入れます: ユーザ、ユーザホーム組織、サービスプロバイダーAAAサーバ、およびサービス設備。
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
これらをIPPに写像して、Userが同じである、UserホームOrganization(含まれているなら)は同じです。 Service Provider AAA ServerとService Equipmentによって密接に同じプロセッサと結合されると予想されます。 言い換えれば、間のインタフェース
Vollbrecht, et al. Informational [Page 28] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [28ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
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).
Service AAA Serverを印刷してください。そうすれば、File Service AAA ServerとFile Serverの間のそれと同様にPrinterは正式なプロトコルを必要としない内部のもの(いくつかの標準の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.
Resourceマネージャの概念、(IPPに比例して[2])にはいくつかのおもしろいねじれがあるのを確実にしてください。 一度始められます、ユーザはサービスにかかわりませんが、印刷が完全になるまで、承認プロセスのパーティーのどれかが状態かキャンセルに印刷セッションについて質問できるのは役に立つように見えます。 ユーザは、特定のセッションまで「付く」方法を必要として、Resourceマネージャ情報にアクセスするのが許容されるために再認可しなければならないかもしれません。
6. Electronic Commerce
6. 電子通商
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.
このセクションはヨーロッパで通常使用される電子商取引アーキテクチャの承認局面について説明します。 私たちは、契約上と信頼関係と交換処理を特定するのにこのモデルを使用するつもりです。 そして、私たちは電子商業のための1セットの承認要件を特定するつもりです。
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].
ほとんどの電子商取引プロトコルが認証とメッセージの保全に焦点を合わせますが、また、[15]でインターネットオープンTradingプロトコル(貿易)作業部会によって説明される電子商取引交換は承認にかかわります。 このセクションはクレジットに備えるSET(安全なElectronic Transaction)と呼ばれる1つの電子商取引プロトコルとデビットカード支払いを調べるでしょう。 私たちは建築観点から承認局面を分析するつもりです。 私たちは[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.
私たちは、標準の承認プロトコルとしてSETを提案しながら、ここにいません。 むしろ、私たちは私たちが承認プロトコルがそのドメインで使用されるために満たされなければならないだろうという要件を引き出すことができるように電子商取引問題ドメインを理解する方法としてSETモデルを調べています。
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]で説明されたものなどの電子商取引プロトコルとメカニズムも、顧客がCyberspaceで安全に買い物をするのを許容するために重要であるかもしれないだけではありませんが、インターネットのサービスの購買には、また、また、重要であるかもしれません。 インターネット輸送サービスが差別化する未来技術で、本来より複雑な価格決定モデルが追加支払金メソッドと同様に必要でしょう。 フレキシブルなサービスの承認は、あるクレジットカードブランドを受け入れるのが認可されるISPで例えば、グローバルに移動しているユーザにプレミアム帯域幅の臨時の配分を許すために重要な一面になるでしょう。
Vollbrecht, et al. Informational [Page 29] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [29ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
6.1. Model Description
6.1. モデル記述
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 コンポーネントの間で交換されたメッセージの系列の考慮。
6.1.1. Identification of Components
6.1.1. コンポーネントの識別
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.
- Cardholder(ユーザ)--購入する要求の後に商品かサービスを受け取って、代金を支払うことになっている人か組織を受けました。 SET用語で、これは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.
- Issuer(ユーザホームOrganization)--それが発行する借り方かクレジットカードを使用するとき、Userを代表して商品かサービスを購入するために許可された取引の代価を払うのを保証する財政的な組織。 財政的な組織(通常銀行かBrand Organization)はユーザアカウントからアカウントまでの転送のお金にパーティーを望んでいます。送ってくださいUserがそれに支払いを命令するものに。 発行されたカードは、Userが支払いにカードを受け入れるのに権限を与えられる商人にカードを使用するのを認可します。 SET用語で、この組織はIssuerと呼ばれます。 この組織は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.
- マーチャント(サービスProvider)--だれがだれが購買をしているか、そして、商品かサービスを提供するのに法的に責任感が強く、支払いの恩恵を受けるかから作られた組織。 SET用語で、この組織はマーチャントと呼ばれます。 Cardholderがマーチャントにとって「外国である」と考えられます。
- 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
- Acquirer(ブローカー)--処理される組織は、カードトランザクションを掛けるか、または借り方に記入します。 この機能は、ほんとうはかなり複雑であるかもしれなく、いくつかの組織にかかるかもしれませんが、私たちは、この組織がSETで定義されるようにAcquirerの役割を実現させるBrand Organizationであると単に思うつもりです。 Acquirerはマーチャントとのアカウントを確立します。 Acquirerは意志が支払い承認要求を受け入れるPaymentゲートウェイを経営します。
Vollbrecht, et al. Informational [Page 30] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [30ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
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.
発行人から商人に権限を与えて、応答を提供します。 Acquirerは承認要求をIssuerに転送するでしょう。 Acquirerはマーチャントへの「ホーム」であると考えられます。
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.
SETドキュメント[16]が注意するように、Brand Organization(クレジットカード組織)はIssuer機能とPaymentゲートウェイを経営するAcquirer機能の両方を扱うかもしれません。 したがって、簡単さのために、私たちは、Broker(アクワイアラ)とUserホームOrganization(発行人)の承認の役割がともにBrand Organizationに属すと思います。
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.
現在より描写的である私たちになるのにSET用語を使用してください。要件部では、これらの用語が再び承認フレームワーク用語まで写像されます。
6.1.2. Identification of Contractual Relationships
6.1.2. 契約上の関係の識別
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.
- Cardholderには、カードIssuerとの契約上の関係があります。 CardholderはIssuerとのアカウントを保持して、口座番号を得ます。
- The Merchant has a contractual relationship with the Acquirer.
The Merchant obtains a Merchant ID from the Acquirer.
- マーチャントには、Acquirerとの契約上の関係があります。 マーチャントは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).
- 本当の世界には、IssuerとAcquirerとのどんなダイレクト契約上の関係もないかもしれません。 Acquirerが支払い承認要求をIssuerにリレーする契約上の関係は、非常に複雑で複数の組織の上に分配されているかもしれません。 しかしながら、簡単さのために、私たちは、AcquirerがIssuerから支払い承認を要求できる適所にある契約があると思います。 これらの契約はBrand Organizationによって容易にされます。 したがって、私たちの簡単な例では、AcquirerとIssuerは同じBrand Organizationに属します。 AcquirerはそれがBank Identification Number(BIN)を必要とするPaymentゲートウェイを経営します。
Vollbrecht, et al. Informational [Page 31] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [31ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
+----------------+ +------------------------+
| Issuer | | Acquirer |
| (User Home | | (Broker) |
| Organization) | | +------------------+ |
| |=======| | Payment | |
| | | | Gateway | |
| | | +------------------+ |
| | | |
+----------------+ +------------------------+
|| ||
|| ||
|| ||
+----------------+ +--------------------+
| Cardholder | | Merchant |
| (User) | | (Service Provider) |---+
| | | | |
| | | | |
| | +--------------------+ |
| | | |
| | | Fulfillment |
| | | |
+----------------+ +----------------------+
+----------------+ +------------------------+ | 発行人| | アクワイアラ| | (ユーザホーム| | (ブローカー)| | 組織) | | +------------------+ | | |=======| | 支払い| | | | | | ゲートウェイ| | | | | +------------------+ | | | | | +----------------+ +------------------------+ || || || || || || +----------------+ +--------------------+ | カード保持者| | 商人| | (ユーザ) | | (サービスプロバイダー) |---+ | | | | | | | | | | | | +--------------------+ | | | | | | | | 遂行| | | | | +----------------+ +----------------------+
Fig. 15 -- SET Contractual Relationships
図15--契約上の関係を設定してください。
6.1.3. Identification of Trust Relationships
6.1.3. 信頼関係の識別
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での静的な信頼関係はSETトランザクションの一部であることが信じられて、認可される必要があるパーティーに発行されるよう証明書に要求する登録手続によって確立されます。 ダイナミックな信頼は支払処理とそのその後の承認要求時点で、作成されます。 識別と登録に基づいた証明書の問題フェーズでは、証明書のユーザが暗黙の静的な承認とメッセージを認証して、保証する手段を得ることに注意してください。 このためにCertificate Authority(カリフォルニア)はSETプロトコルに応じて交換されたメッセージを署名する、そして/または、暗号化するのに使用される証明書を発行するでしょう。
Vollbrecht, et al. Informational [Page 32] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [32ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
6.1.3.1. Static Trust Relationships
6.1.3.1. 静的な信頼関係
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 |
| | | |
+----------------+ +---------------------+
+-------+ | 根| | カリフォルニア| +-------+ カリフォルニア=認証局| Cは証明書と等しいです。| +-----------------+ | ブランド| | カリフォルニア| +-----------------+ | | | | | +-------+ | | |支払い| +----------------+ | | |ゲートウェイ| +----------------------+ | 発行人| | | | カリフォルニア| | アクワイアラ| | (ユーザホーム| +、-、-、-、-、-、-、-、-、--、+| +、-、-、-、-、-、--、+| (ブローカー) | | 組織) | |カード保持者| | | | +----------------+ | | | | カリフォルニア| | +------+--+ C、支払い| | | | +----------+ | 3 | | ゲートウェイ| | | | | | | +----------------+ | | | | +---------+ | | +----------------+ | | 商人| +----------------------+ | | カリフォルニア| | +---------+ | | +----------------+ | | +--------------------+ | カード保持者| | | | 商人| | (ユーザ) | | | | (サービスプロバイダー) |--+ | C-+-----+ | | | | | | 1 +-----------+ C| | | | 2 | | | | | | | | | | +--------------------+ | | | | | | | | 遂行| | | | | +----------------+ +---------------------+
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
- Brand OrganizationはBrandカリフォルニアを操作して、したがって、説明されたドメインの中の一般的な信頼の所有者です。 すべての関係者(カード保持者、Issuer、マーチャント、およびAcquirer)が同じ信頼ドメインのメンバーです。 私たちは別々の状態で3を特定するつもりです。
Vollbrecht, et al. Informational [Page 33] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [33ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
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.
Issuer、Acquirer、およびBrand Organizationを代表して証明書を下付するCAのもの。 階層構造のような木に従って、Brandカリフォルニアは基本的なCAのすべてのものを公認します。 Brandカリフォルニアは独身のRoot Certificate Authorityから信頼を得ます。 どんなパーティーもカリフォルニアからCertificateを入手できる前に、パーティーには、何らかのフォームの契約上の関係がなければなりません。
- 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.
- アカウントがIssuerと共に確立された後に、Cardholderは(1) SETプロトコルで定義されるように一連の登録ステップでCardholderカリフォルニア(CCA)とともに記名しなければなりません。 CCAが登録を承認すると、CardholderはCardholder Certificateを入手するでしょう。 CCAはIssuerを代表してBrand Organizationによって操作されるかもしれません。 Cardholder Certificateは支払いカードの電子表現です。 このプロセスはCardholderとBrandとの信頼関係を作成します。 カード保持者がCardholder Certificateを受け取った後に、Cardholderが認可されたマーチャントに支払いを実行するのが認可されます。
- 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.
- AcquirerからマーチャントIDを得た後に、マーチャントは(2) SETプロトコルで定義されるように一連の登録ステップでマーチャント・カリフォルニア(MCA)とともに記名しなければなりません。 MCAが登録を承認すると、マーチャントはマーチャントCertificateを入手するでしょう。 このプロセスはマーチャントとBrandとの信頼関係を作成します。 MCAはAcquirerを代表してBrand Organizationによって操作されるかもしれません。 登録の後に、Cardholdersから支払請求書を受け入れて、マーチャントがAcquirerのPaymentゲートウェイに承認要求を送るのに権限を与えられます。
- 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.
- 有効なBank Identification Number(BIN)を入手した後に、Acquirerは、PaymentゲートウェイCertificate(3)を入手するために、Paymentゲートウェイカリフォルニア(PCA)とともに記名しなければなりません。 PaymentゲートウェイCertificateは、ゲートウェイが信頼ドメインの中にMerchantsから発する支払い承認要求を受け入れるのを認可します。
- 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.
- AcquirerとIssuerはBrand Organizationを通して信頼関係を持っています。 信頼関係はSETによって定義された手順かメカニズムによって確実にされません、これが支払いサービスを容易にすることにおいて財政的な組織の間の協定で解決された問題であるので。 一方、簡単さのために、私たちは、関係がIssuerへの安全で効率的な方法でAcquirerのゲートウェイによって受け取られた支払い承認要求を転送して、同様に、応答を扱うのを確実にすると思います。
Vollbrecht, et al. Informational [Page 34] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [34ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
6.1.3.2. Dynamic Trust Relationships
6.1.3.2. ダイナミックな信頼関係
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.
Cardholderとマーチャントとのどんな先の確立した静的な信頼関係もないことに注意してください、Cardholderがマーチャントとともに記名する必要はないとき、逆もまた同様です。 信頼関係は、コミュニケーション・プロセスの間、ダイナミックに作成されて、Brandと共に一般的な関係に基づいています。 公開鍵暗号を使用するデジタル署名による、Cardholderのソフトウェアは、マーチャントがBrand Organizationのクレジットカードを受け入れるのに権限を与えられることを確かめることができます。 商人は、CardholderがBrand Organizationのクレジットカードを使用するのが認可されたことを確かめることができます。
6.1.4. Communication Model
6.1.4. コミュニケーションモデル
The purchase request from Cardholder to Merchant and subsequent payment authorization exchange between Merchant and Acquirer is illustrated in figure 17 and described below.
Cardholderからマーチャントまでの購買要求書とマーチャントとAcquirerの間のその後の支払い承認交換は、17図で例証されて、以下で説明されます。
Vollbrecht, et al. Informational [Page 35] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [35ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
+----------------+ +------------------------+
| Issuer | | Acquirer |
| (User Home | | (Broker) |
| Organization) | | +------------------+ |
| |<------+--| Payment | |
| | 5 | | Gateway | |
| |-------+->| | |
| | 6 | +------------------+ |
| | | /|\ | |
+----------------+ +---------+---+----------+
|4 |7
| \|/
+----------------+ +--------------------+
| Cardholder | | Merchant |
| (User) | | (Service Provider) |---+
| |------>| | |
| | 1 | | |
| |<------| | |
| | 2 | | |
| |------>| | |
| | 3 | | |
| |<------| | |
| | 8 | | |
| | | | | |
| | +-----------------+--+ |
| | | |9 |
| |<--------| Fulfillment \|/ |
| | 10 | |
+----------------+ +----------------------+
+----------------+ +------------------------+ | 発行人| | アクワイアラ| | (ユーザホーム| | (ブローカー)| | 組織) | | +------------------+ | | | <、-、-、-、-、--+--| 支払い| | | | 5 | | ゲートウェイ| | | |-------+->|、|、|、|、| 6 | +------------------+ | | | | /|\ | | +----------------+ +---------+---+----------+ |4 |7 | \|/ +----------------+ +--------------------+ | カード保持者| | 商人| | (ユーザ) | | (サービスプロバイダー) |---+ | |、-、-、-、-、--、>|、|、|、|、| 1 | | | | | <、-、-、-、-、--、|、|、|、|、| 2 | | | | |、-、-、-、-、--、>|、|、|、|、| 3 | | | | | <、-、-、-、-、--、|、|、|、|、| 8 | | | | | | | | | | | +-----------------+--+ | | | | |9 | | | <、-、-、-、-、-、-、--、| 遂行、\|/ | | | 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. Cardholderは、買い物をして、merchant.comでいくつかの商品を購入すると決めます。 Cardholderは商品のリストを選択しました、そして、マーチャントのソフトウェアは次に、価格、条件、および受け入れられた支払い方法を示すCardholderのために注文用紙を準備しました。 SETトランザクションは始まります、現在、Cardholderはその人が、ある支払いブランドを使用することで商品の代金を支払いたがっているのを示します。 Cardholderソフトウェアは支払いプロセスを開始するマーチャントに要求を送ります。
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. マーチャントは、Cardholderにマーチャントではなく、ゲートウェイだけに関連している支払指図書(例えば、Cardholderのクレジットカード情報)を暗号化させるAcquirerのゲートウェイから、証明書を含むCardholderにオーダーをチェックして、それに署名して、それを返します。 また、Cardholderはその人の自身の証明書を含んでいます。
Vollbrecht, et al. Informational [Page 36] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [36ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
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. Cardholderは現在、両方の証明書について確かめます(ソフトウェアには、CAのルート証明書があります)。 Cardholderソフトウェアは、オーダー情報を含むメッセージと支払いがそれがCardholderによって署名される指示であると生成します。 ゲートウェイCertificateを使用して、それは、単にゲートウェイで読み込み可能になるようにPayment Instructionを暗号化するでしょう。 Cardholderはその人の証明書を含むでしょう。
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. マーチャントは、Cardholder証明書について確かめて、メッセージの保全をチェックします。 その人は、今、支払いを処理して、支払い承認要求をゲートウェイに出すでしょう。 支払い承認要求はCardholderの証明書とマーチャント証明書の両方を含んでいます。
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. ゲートウェイは、マーチャントの署名証明書と、マーチャントが承認要求に署名したことを確かめます。 次に、それは、会計情報と支払指図書を得て、メッセージの保全とCardholderの証明書をチェックするでしょう。 すべてが適切なオーダーにあると、それは安全な銀行ネットワークを通して承認要求をIssuerに送るでしょう。
6. The issuer returns the authorization.
6. 発行人は承認を返します。
7. The Acquirer's Gateway generates an authorization response which
includes the gateway's certificate.
7. Acquirerのゲートウェイは、承認がゲートウェイの証明書を含んでいる応答であると生成します。
8. The Merchant checks the authorization response and completes the
process by forwarding a purchase response to the Cardholder.
8. マーチャントは、Cardholderへの購買応答を進めることによって、承認応答をチェックして、過程を完了します。
9. The Merchant software authorizes the delivery of the purchased
goods.
9. マーチャントソフトウェアは購入された商品の配送を認可します。
10. The Cardholder receives the purchased goods.
10. Cardholderは購入された商品を受けます。
6.2. Multi Domain Model
6.2. マルチドメインモデル
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.
前の「単一」のドメイン場合では、私たちは、既に複数のCardholders、Merchants、Issuers、およびAcquirersがあると思います。 しかしながら、独身のCCA、MCA、およびPCAしかないとき、これらのすべてのパーティーがただ一つの信頼ドメインに属します。 Acquirerとマーチャントとの信頼関係が同じMCAを使用するとき、同様に、複数のカード保持者と複数のIssuersとの信頼関係は独身のCCAを通って行きます。 CCA、MCA、およびPCAの複数のドメインがあるとき、マルチドメインケースは起こります。 SETでは、これらのドメインは図18で例証される特定のGeopoliticalカリフォルニア(GCA)の下にあります。
Vollbrecht, et al. Informational [Page 37] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [37ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
+-----------+
| 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は国か領域を代表するかもしれません。 アーキテクチャは発行されるとき、これらが、必要があるSET Certificatesを管理して、確かめるのが必要である、更新されるか、または取り消された信頼階層構造を定義します。 それぞれの地政学の領域には、証明書を発行するか、更新するか、または取り消すための異なった方針があるかもしれません。 どんなに一度証明書を発行したことがあっても、同じBrandに属すとまだ異なったGCAのものに属すCardholdersとMerchantsは認識できます。 ヨーロッパのCardholderは米国でこれで商品を購入できるでしょう。米国Acquirerのゲートウェイは、Cardholderが同じBrandに属すと認めて、したがって、支払い承認要求を受け入れるでしょう。
6.3. Requirements
6.3. 要件
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:
多くの電子商取引環境はSETを使用しません。 他のメカニズムはSSL、XML、およびS/MIMEに基づいて存在しています。 また、支払い承認にだけゲートウェイにSETを使用するメカニズムは、存在していて、半分SETとして知られています。 しかしながら、本書では説明されたモデルを使用して、私たちは電子商取引のためのかなり包括的なセットのプロトコル要件を引き出すことができます。 これらの要件では、SET用語は再び記述的モデル用語によって取り替えられます:
Vollbrecht, et al. Informational [Page 38] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [38ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
Cardholder = User
Merchant = Service Provider
Issuer = User Organization
Acquirer = 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. UserからService ProviderまでBrokerを通したService ProviderからUser Organizationまでどんな要求もすることができる前にAuthorizationメカニズムは、信頼関係が確立されるのを許容しなければなりません。 このプロセスは、パーティーが認証されたチャンネルを創造して、そうすることによってそれとなく用法を認可することによってしっかりと交信するのを可能にするでしょう。
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. Userは、Service ProviderがUserホームOrganizationから承認を要求するのを認可できなければなりません。
4. The User must be able to authorize fulfillment of a proposed
service offer from the Service Provider.
4. UserはService Providerから提案されたサービス申し出の遂行を認可できなければなりません。
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. BrokerかService Providerが内容を調べるのを許容しない、UserはBrokerとService Providerを通してセッション承認プロセスに関連している情報をUserホームOrganizationに通過できなければなりません。
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. BrokerかService Providerが内容を調べるのを許容しない、UserホームOrganizationはBrokerとService Providerを通してセッション承認に関連している情報をUserに伝えることができなければなりません。
Nonrepudiation
Nonrepudiation
8. There is a need for a recorded, authenticated and authorized
agreement about the request for and delivery of service.
8. そこで要求に関する協定を記録されたaの必要性であり、認証して、認可する、そして、サービスの配送。
Vollbrecht, et al. Informational [Page 39] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [39ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
7. Computer Based Education and Distance Learning
7. コンピュータ利用教育と通信教育
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.
このセクションは明確に大学の教授陣(部)でコースを取る学生の例について説明しますが、また、同様の環境と例えば、ライブラリローンと電子要約と増刷サービスとコンピュータとネットワークアクセス、マシン(予算管理、店retrievals)が使用するコーヒーメーカーとビルアクセサリーのコピーの使用における他のアプリケーションに、結果として起こる要件も有効であるべきです。
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サーバによる承認がある政策ルールの作成はそうしなければなりません。
7.1. Model Description
7.1. モデル記述
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. コンポーネントの間で交換されたメッセージの系列の考慮。
7.1.1. Identification of Components
7.1.1. コンポーネントの識別
We will consider the components of a distance learning environment in the context of the conceptual entities defined in [2].
私たちは[2]で定義された概念的な実体の文脈の距離学習環境のコンポーネントを考えるつもりです。
Vollbrecht, et al. Informational [Page 40] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [40ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
- The Student (User) -- the person enrolling in a course (Service)
and taking the corresponding exam.
- Student(ユーザ)--コース(サービス)に登録して、対応する試験を受ける人。
- The Educator (Service Equipment) -- the education content server
for which the content is delivered by the Professor.
- Educator(サービスEquipment)--内容が教授によって提供される教育内容サーバ。
- 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.
- Faculty(サービスProvider)--Educatorが1つの例であるService「設備」を制御する組織(米国用語による部)。
- 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.
- Curriculum委員会(UserホームOrganizationの一部)--どれが学生が、あるコースに登録できるか、そして、このコースがどのようにその人の卒業要件に向かって数えられるかによって作成に原因となるボディーは統治します。 学生はいつでも利用可能などんなコースも法的に取るかもしれなくて、しかしながら、Curriculum委員会は、このコースが彼らの卒業を寄付するかどうか決めるでしょう。 Studentが、あるEducatorとともに記名するとき、コースが卒業に向かって数えて、学生と共にこれを確認するか否かに関係なく、EducatorはCurriculum委員会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.
- Student政権(UserホームOrganizationの一部)--財政的な評価基準を含むある評価基準が満たされるなら学生がコースに登録するのを認可する管理編成。 学生の横で、Student政権は、学生のためにどんな試験の成績も動向をおさえて、すべての評価基準が満たされるとき、卒業証書を発行するでしょう。
7.1.2. Identification of Contractual Relationships
7.1.2. 契約上の関係の識別
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つ以上の特定の研究を組み込んで、維持して、発表するのが許容されていて、義務付けられる学部との契約上の関係があると思われます。
Vollbrecht, et al. Informational [Page 41] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [41ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
+---------------------------------------------+
| +-----------------------------------------+ |
| | 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 |
+---------------------------------------------+
+---------------------------------------------+ | +-----------------------------------------+ | | | 教授陣管理| | | |+----------------+ +----------------+| | | |○ 学生| | カリキュラム|| | | *| 政権O*****O委員会|| | |*|| AAAサーバ| | AAAサーバ|| | */|+---O------O-----+ +-----O------O---+| | *//| * * * * | | *// +----*---------*-----------*---------*----+ | *//| * || * * || * | *// | * || * * || * | *// | * || * || * | *// | * || * * || * | *// | * || * * || * | *// | +----*---------*--+ +--*---------*----+ | *// | | * * | | * * | *// | |+---O------O----+| |+----O------O---+| | *// | || 教育者A|| || 教育者B|| | *// | || AAAサーバ|| || AAAサーバ|| | *// | || アドミンを修理してください、|| || アドミンを修理してください、|| | *// | |+---O-----------+| |+-----------O---+| | *// | | * | | * | | +O-------+ | | * | | * | | | | | |+---O-----------+| |+-----------O---+| | | 学生| | || 教育者|| || 教育者|| | | | | || コースA|| || コースB|| | | | | |+---------------+| |+---------------+| | +---------+ | +-----------------+ +-----------------+ | | 教授陣| +---------------------------------------------+
// = 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が中で計算するのが示されるように、StudentにはFacultyとの契約上の関係があります。 契約で、Studentは1セットのコースから成る学習指導要領を追求できます。 コースはEducatorsによってStudentsに提示されます。 学習指導要領は異なったFacultiesからのコースから成るかもしれません。
Faculties have contracts among them allowing Students from one Faculty to enroll in courses from other Faculties.
1FacultyからのStudentsが他のFacultiesからコースに登録するのを許容しながら、学部の中に契約があります。
Vollbrecht, et al. Informational [Page 42] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [42ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
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.
学部はEducatorを実装して、管理しながらFaculty政権と教授の間で契約に基づくEducatorsを例示します。 承認は契約上の関係で1回以上のパーティーによって定義された政策ルールに基づいています。 例えば、しかし、教授が午後、Facultyには方針があるコネだけをコースに与える方針にコースを教授陣xからそれら自身の学生と学生に与えさせる、教授陣yの学生にとって申込みが超過しているとき。
7.1.3. Identification of Trust Relationships
7.1.3. 信頼関係の識別
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.
- 契約に基づく信頼関係は、学習指導要領に属しながら、Facultyと大学の間で教授陣が特定のコースを作成して、教えるのを可能にします。
- 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.
- この例でさらに詳しく述べられませんが、学部の間の信頼関係が、1人の教授陣からの学生が他の学部と共にコースに登録するのを認可することに注意する価値があります。
- 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.
- Educatorの内容に責任がある教授には、教授陣の管理との信頼関係があります。 この関係を通して、教授陣は、教授が条件に該当するCurriculum委員会の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.
- 人がFacultyのStudentになりたがっているとき、契約は、StudentがFacultyのStudent政権とともに記名するのを必要とします。 登録のための必要条件が満たされるなら、Facultyとの信頼関係は、Studentがコースに登録するのを可能にします。 この目的、政権がFacultyの学生IDと情報を含む学生証を発行するStudentに関しては、その人は認められます。 Student政権は、必要な料金を支払うStudentsを認めるだけであり、ある前提条件を満たしていてしまうでしょう。 Student政権は、また、Studentグレードの動向をおさえて、結局、卒業で証明書を下付するでしょう。 Student政権AAAサーバは、関連学生データに近づく手段を持って、認証の指定された手段を持っている認可されたパーティーにグレード情報と他の学生関連の情報を発行するだけでしょう。
Vollbrecht, et al. Informational [Page 43] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [43ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
- 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.
- Curriculum委員会AAAサーバは、学生が必修科目前提条件を満たしたかどうかチェックするためにグレード情報を得るためにStudent政権AAAサーバとの信頼関係を必要とします。 Curriculum委員会は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.
- Educator AAAサーバは、Facultyと共に立つ利益にはこの特定のStudentがあるかを確かめるためにStudent Administrator AAAサーバとの信頼関係を必要とします。 認可されたEducator AAAサーバだけがStudent政権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.
- Educator AAAサーバは、このコースがその人のカリキュラムと一致しているか、または学生がコース前提条件を満たすことにかかわらずEducatorがStudentのための状況報告を得るのを許容するためにCurriculum委員会AAAサーバとの信頼関係を必要とします。 認可されたEducator AAAサーバだけがCurriculum AAA Serverに要求を送るかもしれません。
7.1.4. Sequence of Requests
7.1.4. 要求の系列
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が計算するのを確実にしてください)。
Vollbrecht, et al. Informational [Page 44] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [44ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
+----------------------------------------------+
| |
| +----------------+ 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 |
+----------------------------------------------+
+----------------------------------------------+ | | | +----------------+ 6 +----------------+ | | | 学生|、-、-、-、--、>| カリキュラム| | | | 政権| <、-、-、-、--、| 委員会| | | | AAAサーバ| 5 | AAAサーバ| | | +----------------+ _ +----------------+ | | /|\ | /|/ | | | | / / | | 2,8| |3 / /6 | | | | 4/ / | | | | / / | | | | / / | | | \|/ /|/ | | +---------------+ -- +---------------+ | | | 教育者A| | 教育者B| | | | AAAサーバ| | AAAサーバ| | | +---------------+ +---------------+ | | /|\ | | |2,4,8| |3,6 | +---------+ | | \|/ | | | 1,7 | +---------------+ +---------------+ | | 学生|、-、-、-、-、-、--、>| 教育者| | 教育者| | | | <、-、-、-、-、-、--、| コースA| | コースB| | | | 7,8 | +---------------+ +---------------+ | +---------+ | 教授陣| +----------------------------------------------+
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. 教授がセットアップした後に、Service Equipment(教育者)の学生は、彼らの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. Educatorは、本当に、教授陣から学生に対応していることを決定するためにIDをチェックします。 これはStudent政権とのチェックを含むことができます。
3. The Student Administration replies to the Educator AAA Server, and
the Educator AAA Server replies to the Educator.
3. Student政権はEducator AAA Serverに答えます、そして、Educator AAA ServerはEducatorに答えます。
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. Educatorはそれ自身の方針(単に午後のコース)に対してStudentの要求をチェックして、この学生がコースを取るようにアドバイスされるか否かに関係なく、Curriculum委員会に問い合わせます。 通常、必要事項は、教授によって知られもしませんし、維持もされません。
Vollbrecht, et al. Informational [Page 45] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [45ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
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. Curriculum委員会は、StudentがCurriculum委員会に方針に従った前のコースへの必要なグレードを設定させたかどうか確認するためにStudent政権に対してチェックするかもしれません。
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. Student政権はCurriculum委員会に答えます、そして、Curriculum委員会はEducator AAA Serverに答えます、そして、Educator AAA ServerはEducatorに答えます。
7. If now authorized, the Student is presented the material and the
Student returns completed exams.
7. 現在認可するなら、材料をStudentに寄贈しました、そして、Studentリターンは試験を終了しました。
8. If the Student passes the tests, the Educator informs both the
Student and the Student Administration that the Student has
passed.
8. Studentがテストに合格するなら、Educatorは、Studentが通ったことをStudentとStudent政権の両方に知らせます。
7.2. Requirements
7.2. 要件
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. 収縮したパートナーに権限を委ねるのは可能であるに違いありません。 この要件は限られた例で明白ではありませんが、大学とFacultyとの関係はカリキュラムに関してFacultyに権限の委任を必要とするかもしれません。 予算管理の場合では、この要件は明白です。
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サーバ環境であることは可能です。 これは1人のパートナーが別のパートナーのAAAサーバにはいるように特定の規則を存在に要求するという事実から来ます。 例えば、FacultyはあるチェックがEducatorの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サーバのネットワークを造るのが可能でなければならない、例えば、EducatorからCurriculum委員会までの要求はStudent政権への要求をもたらすかもしれません。
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
4. 学生のグレードのための非拒否をサポートするために取引ログを維持しなければなりません。 この録音は、時間によって押し込まれて、権限のある機関で署名するのを許容するべきです。 学生は試験を受けるために署名するべきです、そして、これはEducatorのAAAによって保たれるべきです。
Vollbrecht, et al. Informational [Page 46] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [46ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
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.
サーバ等級付けの後に、教授は、グレードに署名して、それをStudent Administratorに送ることができるべきであって、Student Administratorの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.
- そして、承認--通知メッセージを会計目的に得るための承認要求と応答、--要求の正しい工事の情報を得て、通知に関するデータベースについて質問するための情報要求と応答。
8. Security Considerations
8. セキュリティ問題
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.
Certificateを結果と考えてください--公開鍵暗号を使用することでデジタルに署名される承認属性を含む構造。
Contract Relationship -- a relation established between two or more
business entities where terms and conditions determine the
exchange of goods or services.
契約Relationship--関係は、2つ以上の企業体の間で条件がどこで商品の、または、サービスの交換を決定するかを確証しました。
Distributed Service -- a service that is provided by more than one
Service Provider acting in concert.
分配されたService--一致した行動を取る1Service Providerによって提供されるサービス。
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.
ダイナミックなTrust Relationship--どんな先の関係も一度も持ったことがない2つの実体の間でダイナミックに作成される安全な関係。 かかわった実体に互いに信じられた第三者がいるなら、この関係を作成できます。 例: それらの両方がクレジットカード組織によって知られているので、商人は支払処理時点で、カード保持者を信じます。
Policy Decision Point (PDP) -- The point where policy decisions are
made.
方針Decision Point(PDP)--政策決定がされるポイント。
Vollbrecht, et al. Informational [Page 47] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [47ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
Policy Enforcement Point (PEP) -- The point where the policy
decisions are actually enforced.
方針Enforcement Point(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 Serverの部品は、AAA Serverかその関連Service Equipmentと交際して、セッションを制御して、モニターされて、調整できるアンカー・ポイントを提供します。
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.)
ローミング--Service ProviderとUserホームOrganizationが2つの異なった組織である承認トランザクション。 (dialinアプリケーションがローミングが活発に考えられたものですが、この定義がまた、他のアプリケーションを包含することに注意してください。)
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]
セキュリティAssociation--1組のノードの間のセキュリティ文脈の収集。ノードは、それらの間で交換されたメッセージについて議定書の中で述べるために適用されるかもしれません。 各文脈は使用中の反復操作による保護の認証アルゴリズム、モード、秘密(共有されたキー、または適切な公衆/秘密鍵組)、およびスタイルを示します。 [14]
Service Equipment -- the equipment which provides a service.
Equipmentを調整してください--サービスを提供する設備。
Service Provider -- an organization which provides a service.
Providerを調整してください--サービスを提供する組織。
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.
静的なTrust Relationship--信じられたパーティーによって作成された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.
ユーザホームOrganization(UHO)--UserにはUserを認証できて、リソースへのアクセスを認可できるかもしれない契約上の関係はある組織かサービス。
References
参照
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[2] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross,
G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA
Authorization Framework", RFC 2904, August 2000.
[2]VollbrechtとJ.とカルフーンとP.とファレルとS.とGommansとL.とGrossとG.とde BruijnとB.とde LaatとC.とHoldregeとM.とD.スペンス、「AAA承認フレームワーク」、RFC2904、2000年8月。
Vollbrecht, et al. Informational [Page 48] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [48ページ]情報のRFC2905AAA承認アプリケーションの例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] ファレルとS.とVollbrechtとJ.とカルフーンとP.とGommansとL.とGrossとG.とde BruijnとB.とde LaatとC.とHoldregeとM.とD.スペンス、「AAA承認要件」、RFC2906、2000年8月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[5] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming
Protocols", RFC 2477, January 1999.
[5]AbobaとB.とG.ゾルン、「ローミングプロトコルを評価する評価基準」、RFC2477、1999年1月。
[6] Beadles, Mark Anthony, and David Mitton, "Criteria for
Evaluating Network Access Server Protocols", Work in Progress.
[6] マークアンソニー、およびデヴィッド・ミットン、「ネットワークアクセス・サーバープロトコルを評価する評価基準」という用務員は、進行中で働いています。
[7] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999.
[7]AbobaとB.とM.用務員、「ネットワークアクセス識別子」、RFC2486、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.とルーベンとA.とシンプソン、W.とS.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2138(1997年4月)。
[9] Calhoun, P. and G. Zorn, "Roamops Authentication/Authorization
Requirements", Work in Progress.
[9] 「Roamops認証/承認要件」というカルフーン、P.、およびG.ゾルンは進行中で働いています。
[10] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[10] パーキンス、C.、「IP移動性サポート」、RFC2002、1996年10月。
[11] Glass, Steven, et al, "Mobile IP Authentication, Authorization,
and Accounting Requirements", Work in Progress.
[11] ガラス、スティーブン、他、「モバイルIP認証、承認、および会計要件」、ProgressのWork。
[12] Hiller, Tom, et al., "cdma2000 Wireless Data Requirements for
AAA", Work in Progress.
[12] ヒラー、トム、他、「AAAのためのcdma2000 Wireless Data Requirements」、ProgressのWork。
[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] ニールソン、ロブ、ジェフ・ウィーラー、フランシスReichmeyer、およびスーザンHares、「Internet2 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に以下を印刷するインターネット」 「モデルと意味論」、RFC2566、4月1999日
[15] Burdett, D., "Internet Open Trading Protocol - IOTP", RFC 2801,
April 2000.
[15] バーデット、D.、「インターネットオープン取り引きは議定書を作ります--IOTP」、RFC2801、4月2000日
[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 。
Vollbrecht, et al. Informational [Page 49] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [49ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
Authors' Addresses
作者のアドレス
John R. Vollbrecht Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA
Vollbrechtが連結するジョンR.はInc.775技術ドライブ、アナーバー、200のスイートMI48108米国をネットワークでつなぎます。
Phone: +1 734 821 1205 Fax: +1 734 821 1235 EMail: jrv@interlinknetworks.com
以下に電話をしてください。 +1 734 821、1205Fax: +1 1235年の734 821メール: jrv@interlinknetworks.com
Pat R. Calhoun Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA
パットR.カルフーンネットワークとセキュリティリサーチセンター、サン・マイクロシステムズ・インク15がネットワークでつなぐSun研究室はメンローパーク、カリフォルニア94025米国を旋回します。
Phone: +1 650 786 7733 Fax: +1 650 786 6445 EMail: pcalhoun@eng.sun.com
以下に電話をしてください。 +1 650 786、7733Fax: +1 6445年の650 786メール: pcalhoun@eng.sun.com
Stephen Farrell Baltimore Technologies 61 Fitzwilliam Lane Dublin 2 Ireland
スティーブンファレルボルチモア技術61フィッツウィリアムレーンダブリン2アイルランド
Phone: +353 1 647 7406 Fax: +353 1 647 7499 EMail: stephen.farrell@baltimore.ie
以下に電話をしてください。 +353 1 647 7406Fax: +353 1 647 7499はメールされます: stephen.farrell@baltimore.ie
Leon Gommans Enterasys Networks EMEA Kerkplein 24 2841 XM Moordrecht The Netherlands
レオンGommans EnterasysはEMEA Kerkplein24 2841XM Moordrechtオランダをネットワークでつなぎます。
Phone: +31 182 379279
email: gommans@cabletron.com
or at University of Utrecht:
l.h.m.gommans@phys.uu.nl
以下に電話をしてください。 +31 182 379279 メール: gommans@cabletron.com かユトレヒト大学で: l.h.m.gommans@phys.uu.nl
Vollbrecht, et al. Informational [Page 50] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [50ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
George M. Gross Lucent Technologies 184 Liberty Corner Road, m.s. LC2N-D13 Warren, NJ 07059 USA
ジョージM.Grossルーセントテクノロジーズ184リバティコーナーRoad、m.s. LC2N-D13ニュージャージー07059ウォレン(米国)
Phone: +1 908 580 4589 Fax: +1 908-580-4991 EMail: gmgross@lucent.com
以下に電話をしてください。 +1 908 580、4589Fax: +1 908-580-4991 メールしてください: gmgross@lucent.com
Betty de Bruijn Interpay Nederland B.V. Eendrachtlaan 315 3526 LB Utrecht The Netherlands
ベティde Bruijn InterpayネーデルラントB.V.Eendrachtlaan315 3526LBユトレヒトオランダ
Phone: +31 30 2835104 EMail: betty@euronet.nl
以下に電話をしてください。 +31 30 2835104はメールされます: betty@euronet.nl
Cees T.A.M. de Laat Physics and Astronomy dept. Utrecht University Pincetonplein 5, 3584CC Utrecht Netherlands
Cees T.午前のde Laat PhysicsとAstronomy dept。 大学Pincetonplein5、ユトレヒト3584CCユトレヒトオランダ
Phone: +31 30 2534585 Phone: +31 30 2537555 EMail: delaat@phys.uu.nl
以下に電話をしてください。 +31 30 2534585は以下に電話をします。 +31 30 2537555はメールされます: delaat@phys.uu.nl
Matt Holdrege ipVerse 223 Ximeno Ave. Long Beach, CA 90803
マットHoldrege ipVerse223Ximeno Ave。 ロングビーチ、カリフォルニア 90803
EMail: matt@ipverse.com
メール: matt@ipverse.com
Vollbrecht, et al. Informational [Page 51] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [51ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
David W. Spence Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA
スペンスが連結するデヴィッドW.はInc.775技術ドライブ、アナーバー、200のスイートMI48108米国をネットワークでつなぎます。
Phone: +1 734 821 1203 Fax: +1 734 821 1235 EMail: dspence@interlinknetworks.com
以下に電話をしてください。 +1 734 821、1203Fax: +1 1235年の734 821メール: dspence@interlinknetworks.com
Vollbrecht, et al. Informational [Page 52] RFC 2905 AAA Authorization Application Examples August 2000
Vollbrecht、他 [52ページ]情報のRFC2905AAA承認アプリケーションの例2000年8月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Vollbrecht, et al. Informational [Page 53]
Vollbrecht、他 情報[53ページ]
一覧
スポンサーリンク
