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