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
Network Working Group J. Vollbrecht
Request for Comments: 2905 Interlink Networks, Inc.
Category: Informational P. Calhoun
Sun Microsystems, Inc.
S. Farrell
Baltimore Technologies
L. Gommans
Enterasys Networks EMEA
G. Gross
Lucent Technologies
B. de Bruijn
Interpay Nederland B.V.
C. de Laat
Utrecht University
M. Holdrege
ipVerse
D. Spence
Interlink Networks, Inc.
August 2000
AAA Authorization Application Examples
AAA授权应用程序示例
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（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
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
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:
本文件是AAAarch RG正在考虑的涉及AAA协议授权要求的三个系列文件之一。这三份文件是：
AAA Authorization Framework [2] AAA Authorization Requirements [3] AAA Authorization Application Examples (this document)
AAA授权框架[2]AAA授权要求[3]AAA授权应用示例（本文档）
In this memo, we examine several important Internet applications that require authorization. For each application, we present a model showing how it might do authorization and then map that model back to the framework presented in [2]. We then present the authorization requirements of the application as well as we presently understand them. The requirements presented in this memo have been collected together, generalized, and presented in [3].
在本备忘录中，我们将研究几个需要授权的重要互联网应用程序。对于每个应用程序，我们提供了一个模型，展示了它如何进行授权，然后将该模型映射回[2]中介绍的框架。然后，我们介绍了应用程序的授权要求，以及我们目前了解的授权要求。本备忘录中提出的要求已汇总、概括并在[3]中提出。
The intent of this memo is to validate and illustrate the framework presented in [2] and to motivate the requirements presented in [3]. This work is intended to be in alignment with the work of the various working groups responsible for the authorization applications illustrated. This memo should not, however, be regarded as authoritative for any of the applications illustrated. Where authoritative documents exist or are in development, they are listed in the references at the end of this document.
本备忘录旨在验证和说明[2]中提出的框架，并激发[3]中提出的要求。这项工作旨在与负责所示授权应用程序的各个工作组的工作保持一致。然而，本备忘录不应被视为对所示任何应用程序的权威。如果存在或正在编制权威文件，则在本文件末尾的参考文件中列出。
The work for this memo was done by a group that originally was the Authorization subgroup of the AAA Working Group of the IETF. When the charter of the AAA working group was changed to focus on MobileIP and NAS requirements, the AAAarch Research Group was chartered within the IRTF to continue and expand the architectural work started by the Authorization subgroup. This memo is one of four which were created by the subgroup. This memo is a starting point for further work within the AAAarch Research Group. It is still a work in progress and is published so that the work will be available for the AAAarch subgroup and others working in this area, not as a definitive description of architecture or requirements.
本备忘录的工作由一个小组完成，该小组最初是IETF AAA工作组的授权小组。当AAA工作组章程更改为侧重于MobileIP和NAS需求时，AAAarch研究组在IRTF内获得了特许，以继续并扩展授权小组开始的体系结构工作。该备忘录是该小组创建的四份备忘录之一。本备忘录是AAAarch研究小组进一步工作的起点。它仍然是一项正在进行的工作，并已发布，以便AAAarch小组和该领域的其他工作人员可以使用该工作，而不是作为架构或需求的最终描述。
This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their negatives, in the way described in RFC 2119 [4].
本文件采用RFC 2119[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.
PPP拨号应用程序使用[2]中讨论的拉入序列。漫游案例使用漫游拉序列，也在[2]中讨论。此序列使用下图1中的拨号漫游术语重新绘制。
+------+ +-------------------------+
| | | Home ISP |
| | | (User Home Organization)|
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | /|\ | |
| | +--------------+---+------+
| | | |
| | |3 |4
| | | |
| | +--------------+---+------+
| | | Visited ISP | | |
| | | | \|/ |
| User | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | /|\ | |
| | | |2 |5 |
| | | | \|/ |
| | 1 | +-------------------+ |
| |------+->| NAS (Service | |
| |<-----+--| Equipment) | |
| | 6 | +-------------------+ |
| | | (Service Provider) |
+------+ PPP +-------------------------+
+------+ +-------------------------+
| | | 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
在这种模式中，用户拨入由访问过的（或外国）ISP（通用模式中的服务提供商）提供的网络访问服务器（NAS）。使用封装在PPP帧（1）中的协议（如PAP、CHAP或EAP）对用户进行身份验证。由于用户尚未获得网络访问权，因此无法向AAA服务器发送IP数据报。此时，用户只能与NAS（服务设备）通信。NAS通过RADIUS[8]或后续AAA协议（2）将用户的认证/授权请求（包括网络访问标识符（NAI）[7]）转发到其自己域中的AAA服务器。访问的ISP的AAA服务器检查来自NAI的域，并将请求转发给用户的主域AAA服务器（3）。归属域AAA服务器根据漫游协议认证用户并授权访问。归属域AAA服务器可能返回服务参数
(e.g. Idle-Timeout) to the visited ISP's AAA server (4) which forwards them to the NAS, possibly adding additional service parameters (5). The NAS completes PPP session initialization (6).
（例如，空闲超时）到访问的ISP的AAA服务器（4），该服务器将它们转发到NAS，可能会添加额外的服务参数（5）。NAS完成PPP会话初始化（6）。
In the future, this model may be expanded in several ways [9]. For instance, Authentication and Authorization may be done in separate passes using different servers in order to support specialized forms of authentication. Or to better support roaming, a broker may be inserted between the visited ISP and the home ISP. Or authorization may be supported based on other identifiers such as the caller ID and called ID obtained from the PSTN (e.g., using ANI and DNIS).
未来，该模型可能会以多种方式扩展[9]。例如，身份验证和授权可以使用不同的服务器在单独的过程中完成，以支持特殊形式的身份验证。或者，为了更好地支持漫游，可以在访问的ISP和家庭ISP之间插入代理。或者，可以基于诸如从PSTN获得的呼叫者ID和被叫ID等其他标识符（例如，使用ANI和DNIS）来支持授权。
The following requirements are identified in [9] for authorizing PPP dialin service using roaming.
[9]中确定了使用漫游授权PPP拨号服务的以下要求。
- 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，该服务器或PDP可能在同一管理域内，也可能不在同一管理域内。
- The AAA protocol MUST allow for intermediate brokers to add their own local Authorization information to a request or response.
- AAA协议必须允许中间代理将其自己的本地授权信息添加到请求或响应中。
- When a broker is involved, the protocol MUST provide end to end security.
- 当涉及代理时，协议必须提供端到端安全性。
- The broker MUST be able to return a forwarding address to a requester, allowing two nodes to communicate together.
- 代理必须能够向请求者返回转发地址，从而允许两个节点一起通信。
- 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协议用于管理IP主机跨IP子网的移动性[10]。移动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].
[11]中记录了移动IP授权的要求。在本节中，我们为移动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 |
| | | | | |
+---------+ +---------+ +---------+
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 |
+--------+
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:
在此示例中，移动节点出现在外部网络中，并向外部代理发出注册。由于外部代理不与归属代理共享任何安全关联，因此它向其本地AAA服务器发送AAA请求，其中包括身份验证信息和移动IP注册请求。移动节点无法直接与家庭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地址，并且可能正在请求由其归属提供商向其分配IP地址。
The Foreign AAA Server will determine whether the request can be satisfied locally through the use of the Network Access Identifier [7] provided by the Mobile Node. The NAI has the format of user@realm and the AAA Server uses the realm portion of the NAI to identify the Mobile Node's home AAA Server. If the Foreign AAA Server does not share any security association with the Mobile Node's home AAA Server, it may forward the request to its broker. If the broker has a relationship with the home network, it can forward the request, otherwise a failed response is sent back to the Foreign AAA Server.
外部AAA服务器将通过使用移动节点提供的网络接入标识符[7]来确定是否可以在本地满足请求。NAI的格式为user@realmAAA服务器使用NAI的领域部分来识别移动节点的家庭AAA服务器。如果外部AAA服务器不与移动节点的家庭AAA服务器共享任何安全关联，则它可以将请求转发给其代理。如果代理与家庭网络有关系，它可以转发请求，否则将失败的响应发送回外部AAA服务器。
When the home AAA Server receives the AAA Request, it authenticates the user and begins the authorization phase. The authorization phase includes the generation of:
当家庭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.
为了允许跨管理域扩展无线数据访问，有必要最小化所需的安全关联。这意味着每个外国代理不与Internet上的每个本国代理共享安全关联。移动代理与其本地AAA服务器共享安全关联，而本地AAA服务器又与其他AAA服务器共享安全关联。同样，根据漫游运营（roamops）工作组的定义，使用代理可以通过减少提供商建立的关系数量来扩展此类服务。
After a Mobile Node is authenticated, the authorization phase includes the generation of Sessions Keys. Specifically, three keys are generated:
在移动节点被认证之后，授权阶段包括会话密钥的生成。具体而言，将生成三个键：
- k1 - Key to be shared between the Mobile Node and the Home Agent - k2 - Key to be shared between the Mobile Node and the Foreign Agent - k3 - Key to be shared between the Foreign Agent and the Home Agent
- k1-移动节点和归属代理之间共享的密钥-k2-移动节点和外部代理之间共享的密钥-k3-外部代理和归属代理之间共享的密钥
Each Key is propagated to each mobility device through the AAA protocol (for the Foreign and Home Agent) and via Mobile-IP for the Mobile Node (since the Mobile Node does not interface directly with the AAA servers).
每个密钥通过AAA协议（对于外部和本地代理）和移动节点的移动IP（因为移动节点不直接与AAA服务器接口）传播到每个移动设备。
Figure 4 depicts the new security associations used for Mobile-IP message integrity using the keys derived by the AAA server.
图4描述了使用AAA服务器派生的密钥用于移动IP消息完整性的新安全关联。
+--------+ +--------+
| | k3 | |
| FA |======================| HA |
| | | |
+--------+ +--------+
\\ //
\\ k2 k1 //
\\ +--------+ //
\\ | | //
\=====| MN |=====/
| |
+--------+
+--------+ +--------+
| | 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. 如果AAA协议允许在认证/授权请求中嵌入移动IP注册消息，这将进一步减少所需的往返次数，从而减少连接时间。
6. It must be possible to pass Mobile-IP specific key management data along with the authorization data. This allows the AAA server to act as a Key Distribution Center (KDC).
6. 必须能够将特定于移动IP的密钥管理数据与授权数据一起传递。这允许AAA服务器充当密钥分发中心（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. 授权响应应允许区分服务（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咨询委员会讨论的带宽代理体系结构衍生的授权方面。我们使用授权模型概念来识别契约关系和信任关系，并提供可能的消息交换。我们将从我们的体系结构模型中导出带宽代理的一组授权需求。Internet 2 Qbone BB咨询委员会研究基于两层授权概念的单域和多域实现。三层模型被视为未来的工作项，因此不属于本说明的一部分。有关Internet 2带宽代理工作及其概念的信息，请访问：
http://www.merit.edu/working.groups/i2-qbone-bb
http://www.merit.edu/working.groups/i2-qbone-bb
The material in this section is based on [13] which is a work in progress of the Internet2 Qbone BB Advisory Council.
本节中的材料基于[13]，这是Internet2 Qbone BB咨询委员会正在进行的工作。
The establishment of a model involves four steps:
模型的建立包括四个步骤：
1. identification of the components that are involved and what they are called in this specific environment, 2. identification of the relationships between the involved parties that are based on some form of agreement, 3. identification of the relationships that are based on trust, and 4. consideration of the sequence of messages exchanged between components.
1. 识别所涉及的组件及其在该特定环境中的名称，2。确定基于某种形式协议的相关方之间的关系，3。识别基于信任的关系，以及4。考虑组件之间交换的消息序列。
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 ]中定义的概念实体的上下文中，我们将考虑带宽代理事务的组件。带宽代理两层模型识别控制服务设备的用户和服务提供商。
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).
- 服务用户（User）——通过请求在选定的目的地和自身之间分配可量化的资源，愿意使用一定级别的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.
注：在[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
+-------------+
| |
| +---------+ |
| |Bandwidth| |
+-------+ | |Broker | |
| | | | | |
|Service| | +---------+ |
|User |=========| |
| | | +---------+ |
| | | | Network | |
+-------+ | | Routing | |
| | Devices | |
| +---------+ |
| Autonomous |
| Service |
| Domain |
+-------------+
==== contractual
relationship
Fig. 5 -- Two-Tier Single Domain Contractual Relationships
图5——两层单域契约关系
In the multi-domain case, the User has a contract with a single Service Provider. This Service Provider has a contract with neighboring Service Providers. This model is used when independent autonomous networks establish contracts with each other.
在多域情况下，用户与单个服务提供商签订了合同。此服务提供商与相邻的服务提供商签订了合同。当独立的自治网络彼此建立契约时，使用该模型。
+-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |Bandwidth| | | |Bandwidth| |
+-------+ | |Broker | | | |Broker | |
| | | | | | | | | |
|Service| | +---------+ | | +---------+ |
|User |=========| |========| |
| | | +---------+ | | +---------+ |
| | | | Network | | | | Network | |
+-------+ | | Routing | | | | Routing | |
| | Devices | | | | Devices | |
| +---------+ | | +---------+ |
| Autonomous | | Autonomous |
| Service | | Service |
| Domain A | | Domain B |
+-------------+ +-------------+
+-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |Bandwidth| | | |Bandwidth| |
+-------+ | |Broker | | | |Broker | |
| | | | | | | | | |
|Service| | +---------+ | | +---------+ |
|User |=========| |========| |
| | | +---------+ | | +---------+ |
| | | | Network | | | | Network | |
+-------+ | | Routing | | | | Routing | |
| | Devices | | | | Devices | |
| +---------+ | | +---------+ |
| Autonomous | | Autonomous |
| Service | | Service |
| Domain A | | Domain B |
+-------------+ +-------------+
==== contractual
relationship
==== contractual
relationship
Fig. 6 -- Two-Tier Multi-Domain Contractual Relationships
图6——两层多域合约关系
Contractual relationships may be independent of how trust, which is necessary to facilitate authenticated and possibly secure communication, is implemented. There are several alternatives in the Bandwidth Broker environment to create trusted relationships. Figures 7 and 8 show two alternatives that are options in the two-tier Bandwidth Broker model.
契约关系可能独立于信任的实现方式，而信任是促进经过认证且可能安全的通信所必需的。在带宽代理环境中，有几种可供选择的方法来创建信任关系。图7和图8显示了两个备选方案，它们是两层带宽代理模型中的选项。
+-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |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 |
+-------------+ +-------------+
+-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |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
==== contractual relationship
O**O trust relationship
Fig. 7 -- Two-Tier Multi-Domain Trust Relationships, alt 1
图7——两层多域信任关系，alt 1
+-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |Bandwidth| | | |Bandwidth| |
+-------+ | |Broker | | | |Broker | |
| | | | | | | | | |
|Service| | +----O----+ | | +----O----+ |
|User |=========| * |========| * |
| | | +----O----+ | | +----O----+ |
| O***********O Network O************O Network | |
+-------+ | | Routing | | | | Routing | |
| | Devices | | | | Devices | |
| +---------+ | | +---------+ |
| Autonomous | | Autonomous |
| Service | | Service |
| Domain A | | Domain B |
+-------------+ +-------------+
+-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |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
==== contractual relationship
O**O trust relationship
Fig. 8 -- Two-Tier Multi-Domain Trust Relationships, alt 2
图8——两层多域信任关系，alt 2
Although [13] does not recommend specifics regarding this question, the document recognizes the need for trust relationships. In the first model, a trust relationship, based on some form of authentication method, is created between the User and the Bandwidth Broker and among Bandwidth Brokers. In the second model, which enjoys some popularity in enterprise networks, the trust relationship may be established via the wiring closet and the knowledge of which physical router port or MAC address is connected to which user. The router-Bandwidth Broker relationship may be established physically or by some other authentication method or secure channel.
尽管[13]没有建议关于这个问题的具体细节，但该文件承认信任关系的必要性。在第一个模型中，基于某种形式的身份验证方法，在用户和带宽代理之间以及在带宽代理之间创建信任关系。第二个模型在企业网络中颇受欢迎，它可以通过布线柜和哪个物理路由器端口或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注册，以便加入信任域。路由器带宽代理关系可以如前两幅图中所述建立。关于这种模型的一个有趣的观察结果是，域B中的带宽代理可以通过域A中的带宽代理将信息路由给用户，而BB1无法读取信息（使用端到端安全性）。该模型通过树状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 |
+-------------+ +-------------+
+-------------------+
| 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
==== contractual relationship
O**O trust relationship
{C}. certification process
Fig. 9 -- Two-Tier Multi-Domain Trust Relationships, alt 3
图9——两层多域信任关系，alt 3
When describing the Bandwidth Broker communication model, it is important to recognize that trust relationships between components must ensure secure and authenticated communication between the involved components. As the Internet 2 Qbone Bandwidth Broker work does not recommend any particular trust relationship model, we make the same assumptions as [13]. In theory, the trust model and communication model can be independent, however communication efficiency will determine the most logical approach.
在描述带宽代理通信模型时，必须认识到组件之间的信任关系必须确保相关组件之间的通信安全且经过身份验证。由于Internet 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.
当前的Internet 2 Qbone带宽代理讨论描述了一个两层模型，其中带宽代理接受来自属于其域的用户的资源分配请求（RAR）或来自相邻域的上游带宽代理生成的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。SL是在单向意义上建立的。两个SLS必须控制双向连接。SL建立在聚合数据流和为这些流提供的资源（带宽）的级别上。
A Bandwidth Broker may honor an inter-domain RAR by applying policy decisions determining that a particular RAR does fit into a pre-established SLS. If successful, the Bandwidth Broker will authorize the usage of the bandwidth. If unsuccessful, the Bandwidth Broker may deny the request or approve the request after it has re-negotiated the SLS with its downstream Bandwidth Broker.
带宽代理可以通过应用确定特定RAR是否适合预先建立的SLS的策略决策来尊重域间RAR。如果成功，带宽代理将授权使用带宽。如果不成功，带宽代理可以拒绝请求或在其与下游带宽代理重新协商SLS后批准请求。
A separate Policy Manager may be involved in the CAC decision. The Internet 2 Qbone Bandwidth Broker discussion recognizes an ideal environment where Bandwidth Brokers and Policy Managers work together to provide CAC using integrated policy services [13].
CAC决策可能涉及一名单独的政策经理。Internet 2 Qbone带宽代理讨论确认了一个理想的环境，在这个环境中，带宽代理和策略管理人员共同工作，使用集成策略服务提供CAC[13]。
The Internet 2 Qbone Bandwidth Broker discussion proposes development of the Bandwidth Broker model in several phases:
Internet 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仅在本地域内处理。SL是使用手动方法（传真、电子邮件）预先建立的。
- Phase 1: Informed Admission. RAR's spanning multiple domains are authorized based on information obtained from one or more Bandwidth Brokers along the path.
- 第一阶段：知情入院。跨多个域的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.
尽管解决了本地准入问题，但当前的Internet 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.
带宽代理之间的两种基本信令方法已被确定用于知情接纳情况。如图10所示。
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| |RAR | | 1 | | 2 | |
| User |-------->| |-------->| |-------->| |
| | RAA | BB1 | 4 | BB2 | 3 | BB3 |
| |<--------| |<--------| |<--------| |
| | | | | | | |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| |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 | |
| |<--------| |<--------| |<--------| |
+-------+ +-------+ +-------+ +-------+
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| |RAR | | 1 | | 3 | |
| User |-------->| |-------->| |-------->| |
| | RAA | BB1 | 2 | BB2 | 4 | BB3 |
| |<--------| |<--------| |<--------| |
| | 7 | | 6 | | 5 | |
| |<--------| |<--------| |<--------| |
+-------+ +-------+ +-------+ +-------+
B) Immediate response signaling.
B） 即时反应信号。
Fig. 10 -- Fundamental Signalling Approaches
图10——基本信令方法
- End to End signaling. An RAR from a User to BB1 is forwarded to BB2 (1). BB2 will forward the request to BB3 (2). If BB3 is the destination of the request, BB3 will authorize the request and reply to BB2 (3). BB2 will then reply to BB1 (4), and BB1 will send a Resource Allocation Answer (RAA) back to the User to complete the authorization.
- 端到端信令。从用户到BB1的RAR被转发到BB2（1）。BB2将请求转发给BB3（2）。如果BB3是请求的目的地，BB3将授权请求并回复BB2（3）。然后，BB2将回复BB1（4），BB1将向用户发送资源分配应答（RAA）以完成授权。
- Immediate response signaling. This is the case where BB1 will want to authorize an RAR from its domain and forwards the authorization request to BB2 (1). If BB2 approves, the response is immediately returned to BB1 (2). BB1 will send an RAA back to the User. If the authorization was positive BB2 will forward subsequently a request to the next BB, BB3 (3). BB3 authorizes the request and responds to BB2 (4). If the response is negative (5), BB2 will cancel the authorization it previously issued to BB1 (6) and this will result in a cancellation from BB1 to the user (7). In this case the RAA authorization is valid until revoked by 7.
- 即时反应信号。这种情况下，BB1希望从其域授权RAR，并将授权请求转发给BB2（1）。如果BB2批准，响应将立即返回给BB1（2）。BB1将向用户发回RAA。如果授权是肯定的，BB2将随后向下一个BB转发请求，BB3（3）。BB3授权请求并响应BB2（4）。如果响应为否定（5），BB2将取消其先前向BB1（6）发出的授权，这将导致从BB1向用户（7）取消授权。在这种情况下，RAA授权在7之前有效。
Figure 11 shows components of the discussed Bandwidth Broker architecture with its interfaces.
图11显示了所讨论的带宽代理体系结构及其接口的组件。
- An intra-domain interface allows communication with all the service components within the network that the Bandwidth Broker controls.
- 域内接口允许与带宽代理控制的网络内的所有服务组件进行通信。
- An inter-domain interface allows communication between Bandwidth Brokers of different autonomous networks.
- 域间接口允许不同自治网络的带宽代理之间进行通信。
- A user/application interface allows the Bandwidth Broker to be managed manually. Requests can be sent from the User or a host application.
- 用户/应用程序界面允许手动管理带宽代理。可以从用户或主机应用程序发送请求。
- A policy manager interface allows implementation of complex policy management or admission control.
- 策略管理器接口允许实现复杂的策略管理或准入控制。
- A routing table interface allows the Bandwidth Broker to understand the network topology.
- 路由表接口允许带宽代理了解网络拓扑。
- An NMS interface allows coordination of network provisioning and monitoring.
- NMS接口允许协调网络供应和监控。
adjacent BB <---------------------------> adjacent BB
|
V
+------------------------------+
| | inter-domain | |
| -------------- ------|
application | | PM |
server \ | |iface |
\ |------- ---------+ ------|
->| user/ | | simple | ------|
user/host-->| app | | policy | | NMS |
->| iface | | services| |iface |
/ |------- ---------+ ------|
network / | |
operator | ------- ------- |
| | data | |routing| |
| | store | |info | |
| | | | | |
| ------- ------- |
| |
| ---------------- |
| | intra-domain | |
+------------------------------+
^
|
edge router(s) <---------------------------> edge router(s)
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).
在带宽代理可以配置两个相邻域之间的服务之前，它们必须建立并初始化关系。不使用身份验证；因此，任何信任关系都是隐含的。初始化的一部分是拓扑信息的交换（相邻带宽代理的列表）。
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
生成服务设置请求（SSR）（由运营商根据需要或在系统启动时）并转发给下游带宽代理。下游带宽代理将检查
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.
与自身的服务级别规范保持一致，并通过设置应答消息（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引用打印允许用户请求打印服务打印特定文件。用户创建在打印机（或一组打印机之一）上打印特定文件的请求。关键的方面是请求只包括文件名，而不包括文件内容。然后，打印服务必须在打印之前从文件服务器读取文件。文件服务器和打印服务器都必须授权该请求。一旦启动，打印将在用户不干预的情况下完成；i、 例如，文件将直接发送到打印服务，而不是通过用户发送到打印机。
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.
假设打印机和文件服务器可能由不同的组织拥有和操作。关于如何建立“协议”，似乎有两种模式。
1. User has agreement with Print Server; Print Server has agreement with File Server.
1. 用户与打印服务器有协议；打印服务器与文件服务器有协议。
2. User has agreements with both File and Print Server directly.
2. 用户直接与文件服务器和打印服务器都有协议。
In case 1, the user has a trust relationship with the Print Service AAA Server. The Printer forwards the request to the File Server. The File Server authorizes the Printer and determines if the Printer is allowed access to the file. Note that while there may be some cases where a Print Server may on its own be allowed access to files (perhaps some "public files", or that can only be printed on certain "secure" printers), it is normally the case that files are associated with users and not with printers. This is not a good "generic" model as it tends to make the print service an attractive point of attack.
在案例1中，用户与打印服务AAA服务器具有信任关系。打印机将请求转发到文件服务器。文件服务器授权打印机并确定是否允许打印机访问文件。请注意，在某些情况下，可能允许打印服务器自己访问文件（可能是一些“公共文件”，或只能在某些“安全”打印机上打印的文件），但通常情况下，文件与用户关联，而不是与打印机关联。这不是一个好的“通用”模型，因为它往往使打印服务成为一个有吸引力的攻击点。
+------+ +----------------------+
| | | File Service |----+
| | | AAA Server |<-+ |
| | +----------------------+ | |
| | | | | |
| | | File Server | | |
| | | | | |
| User | +----------------------+ | |
| | | |
| | | |
| | | |
| | +----------------------+ | |
| |------>| Print Service |--+ |
| |<------| AAA Server |<---+
| | +----------------------+
| | | Print Server |
| | | and Printer |
+------+ +----------------------+
+------+ +----------------------+
| | | 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 |
+------+ +----------------------+
+------+ +----------------------+
| |------>| 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 |<---+
+------+ +----------------------+
+------+ +----------------------+
| |------>| 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。文件服务器信任AC，因为它由文件服务AAA服务器签名并允许（或不允许）会话。
It is interesting to note that an AC could also be created and signed by the User, and passed from the Print Server to the File Server. The File Server would need to be able to recognize the User's signature. Yet another possibility is that the Print Service AAA Server could simply authenticate the User and then request an AC from the File Service AAA Server.
有趣的是，用户还可以创建和签署AC，并将其从打印服务器传递到文件服务器。文件服务器需要能够识别用户的签名。还有一种可能性是打印服务AAA服务器可以简单地对用户进行身份验证，然后从文件服务AAA服务器请求AC。
The descriptive model presented in [2] includes four basic elements: User, User Home Organization, Service Provider AAA Server, and Service Equipment.
[2]中介绍的描述模型包括四个基本元素：用户、用户主组织、服务提供商AAA服务器和服务设备。
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].
尽管大多数电子商务协议侧重于认证和消息完整性，但互联网开放交易协议（trade）工作组在[15]中描述的电子商务交换也涉及授权。本节将研究一种称为SET（安全电子交易）的电子商务协议，该协议提供信用卡和借记卡支付。我们将从体系结构的角度分析授权方面。我们将应用[2]中定义的概念和术语。
We are not here proposing SET as a standard authorization protocol. Rather, we are examining the SET model as a way of understanding the e-commerce problem domain so that we can derive requirements that an authorization protocol would have to meet in order to be used in that domain.
我们在这里不建议将SET作为标准授权协议。相反，我们正在研究SET模型，将其作为理解电子商务问题域的一种方式，以便我们能够导出授权协议必须满足的需求，以便在该域中使用。
E-commerce protocols and mechanisms such as those described in [16] may not only be important to allow customers to shop safely in Cyberspace, but may also be important for purchases of Internet services as well. With emerging technologies allowing Internet transport services to be differentiated, an inherently more complex pricing model will be required as well as additional payment methods. Flexible authorization of services will be an important aspect to allow, for example, globally roaming users ad hoc allocation of premium bandwidth with an ISP who is authorized to accept certain credit card brands.
电子商务协议和机制（如[16]中所述）可能不仅对允许客户在网络空间安全购物很重要，而且对购买互联网服务也很重要。随着新兴技术的出现，互联网运输服务得以区别对待，将需要一个固有的更复杂的定价模型以及额外的支付方式。灵活的服务授权将是一个重要方面，例如，允许全球漫游用户与授权接受某些信用卡品牌的ISP临时分配优质带宽。
The establishment of a model involves four steps:
模型的建立包括四个步骤：
1. identification of the components that are involved and what they are called in this specific environment, 2. identification of the relationships between the involved parties that are based on some form of agreement, 3. identification of the relationships that are based on trust, and 4. consideration of the sequence of messages exchanged between components.
1. 识别所涉及的组件及其在该特定环境中的名称，2。确定基于某种形式协议的相关方之间的关系，3。识别基于信任的关系，以及4。考虑组件之间交换的消息序列。
We will consider the components of an electronic commerce transaction in the context of the conceptual entities defined in [2].
在[2 ]中定义的概念实体的上下文中，我们将考虑电子商务交易的组成部分。
- The Cardholder (User) -- the person or organization that is to receive and pay for the goods or services after a request to purchase has been received. In SET terms this is called a Cardholder.
- 持卡人（用户）——在收到购买请求后接收并支付商品或服务的个人或组织。按规定，这被称为持卡人。
- The Issuer (User Home Organization) -- the financial organization that guarantees to pay for authorized transactions to purchase goods or services on behalf of the User when using a debit or credit card it issues. The financial organization (typically a bank or Brand Organization) will transfer money from the user account to the account the party to which the User instructs it to send the payment. The issued card authorizes the User to use the card for payments to merchants who are authorized to accept the card. In SET terms this organization is called the Issuer. This organization is considered "home" to the Cardholder.
- 发卡机构（用户母国组织）——在使用其发行的借记卡或信用卡时，保证代表用户支付授权交易以购买商品或服务的金融组织。财务组织（通常是银行或品牌组织）将资金从用户帐户转移到用户指示其付款的一方的帐户。发行的卡授权用户使用该卡向有权接受该卡的商户付款。按规定，这个组织被称为发行人。该组织被视为持卡人的“家”。
- The Merchant (Service Provider) -- the organization from whom the purchase is being made and who is legally responsible for providing the goods or services and receives the benefit of the payment made. In SET terms this organization is called a Merchant. The Cardholder is considered to be "foreign" to the Merchant.
- 商户（服务提供商）——进行购买的组织，对提供商品或服务负有法律责任，并从支付的款项中受益。按规定，这个组织被称为商人。持卡人被视为商户的“外国人”。
- The Acquirer (Broker) -- the organization that processes credit or debit card transactions. Although in reality this function may be rather complex and may span several organizations, we will simply assume this organization to be a Brand Organization fulfilling the role of the Acquirer as defined in SET. The Acquirer establishes an account with the Merchant. The Acquirer operates a Payment Gateway that will accept payment authorization requests from
- 收单机构（经纪人）——处理信用卡或借记卡交易的组织。尽管在现实中，该职能可能相当复杂，并且可能跨越多个组织，但我们将简单地假设该组织是一个品牌组织，履行SET中定义的收单机构的角色。收单机构与商户建立账户。收单机构运营一个支付网关，该网关将接受来自的支付授权请求
authorized merchants and provide responses from the issuer. The Acquirer will forward an authorization request to the Issuer. The Acquirer is considered "home" to the Merchant.
授权商户并提供发卡机构的回复。收单机构将向发卡机构转发授权请求。收单机构被视为商户的“家”。
As the SET document [16] notes, a Brand Organization (credit card organization) may handle both the Issuer function and Acquirer function that operates a Payment Gateway. For simplicity, we therefore assume that the authorization role of Broker (Acquirer) and User Home Organization (Issuer) both belong to the Brand Organization.
如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.
为了更具描述性，我们现在使用集合术语。在“需求”部分，这些术语将再次映射回授权框架术语。
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 |
| | | |
+----------------+ +----------------------+
+----------------+ +------------------------+
| Issuer | | Acquirer |
| (User Home | | (Broker) |
| Organization) | | +------------------+ |
| |=======| | Payment | |
| | | | Gateway | |
| | | +------------------+ |
| | | |
+----------------+ +------------------------+
|| ||
|| ||
|| ||
+----------------+ +--------------------+
| Cardholder | | Merchant |
| (User) | | (Service Provider) |---+
| | | | |
| | | | |
| | +--------------------+ |
| | | |
| | | Fulfillment |
| | | |
+----------------+ +----------------------+
Fig. 15 -- SET Contractual Relationships
图15——设置合同关系
It is important to recognize that there are two kinds of trust relationships: static and dynamic trust relationships. Static trust relationships in SET are established by means of a registration process that will request a certificate to be issued to the party that needs to be trusted and authorized to be part of a SET transaction. Dynamic trust is created at the time of a payment transaction and its subsequent authorization request. Note that at the issue phase of a certificate, based on identification and registration, the user of the certificate gets an implicit static authorization and a means of authenticating and securing messages. For this purpose a Certificate Authority (CA) will issue certificates that are used to sign and/or encrypt messages exchanged according to the SET protocol.
重要的是要认识到有两种信任关系：静态和动态信任关系。SET中的静态信任关系是通过注册过程建立的，注册过程将请求向需要信任和授权成为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 |
| | | |
+----------------+ +---------------------+
+-------+
| Root |
| CA |
+-------+ CA = Certificate Authority
| {C} = Certificate
|
+-----------------+
| Brand |
| CA |
+-----------------+
| | |
| | +-------+
| | |Payment|
+----------------+ | | |Gateway| +----------------------+
| Issuer | | | | CA | | Acquirer |
| (User Home | +----------+ | +-------+ | (Broker) |
| Organization) | |Cardholder| | | | +----------------+ |
| | | CA | | +------+--+-{C} Payment | |
| | +----------+ | 3 | | Gateway | |
| | | | | +----------------+ |
| | | +---------+ | |
+----------------+ | | Merchant| +----------------------+
| | CA |
| +---------+
| |
+----------------+ | | +--------------------+
| Cardholder | | | | Merchant |
| (User) | | | | (Service Provider) |--+
| {C}-+-----+ | | | |
| | 1 +-----------+-{C} | |
| | 2 | | |
| | | | |
| | +--------------------+ |
| | | |
| | | Fulfillment |
| | | |
+----------------+ +---------------------+
Fig. 16 -- SET Trust Relationships within a Brand Domain
图16——在品牌领域内设置信任关系
- The Brand Organization operates a Brand CA and is therefore the holder of the common trust within the described domain. All involved parties (Cardholder, Issuer, Merchant and Acquirer) are members of the same trust domain. We will identify three separate
- 品牌组织经营品牌CA，因此是所述领域内共同信任的持有人。所有相关方（持卡人、发卡机构、商户和收单机构）均为同一信托域的成员。我们将确定三个独立的
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 | |
+----------------+ +----------------------+
+----------------+ +------------------------+
| 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购物并决定购买一些商品。持卡人选择了一份商品清单，商户软件随后为持卡人准备了一份订单，注明价格、条款和条件以及可接受的付款方式。设定交易从持卡人表示他或她希望使用某个支付品牌支付商品时开始。持卡人软件向发起支付流程的商户发送请求。
2. The Merchant checks the order and signs it and returns it to the Cardholder including a certificate from the Acquirer's Gateway that allows the Cardholder to encrypt payment instructions that are only relevant to the Gateway and not to the Merchant (e.g., the Cardholder's credit card information). The Cardholder also includes his or her own certificate.
2. 商户检查订单并签字，然后将其返回给持卡人，包括收单机构网关的证书，该证书允许持卡人加密仅与网关相关而与商户无关的支付指令（例如，持卡人的信用卡信息）。持卡人还包括他或她自己的证书。
3. The Cardholder now verifies both certificates (the software has the CA's root certificate). The Cardholder software generates a message containing the order information and the payment instructions that is signed by the Cardholder. Using the Gateway Certificate, it will encrypt the Payment Instruction so that it will only be readable by the Gateway. The Cardholder will include his or her certificate.
3. 持卡人现在验证两个证书（软件具有CA的根证书）。持卡人软件生成一条包含订单信息和由持卡人签署的支付指令的消息。使用网关证书，它将加密支付指令，使其仅可由网关读取。持卡人将包括其证书。
4. The Merchant verifies the Cardholder certificate and checks the message integrity. He or she will now process the payment and issue a payment authorization request to the gateway. The payment authorization request contains the Cardholder's certificate and both Merchant certificates.
4. 商户验证持卡人证书并检查消息完整性。他或她现在将处理付款并向网关发出付款授权请求。支付授权请求包含持卡人证书和两个商户证书。
5. The Gateway verifies the Merchant's signature certificate and that the Merchant signed the authorization request. Next it will obtain the account information and payment instructions and will check the message integrity and the Cardholder's certificate. If everything is in proper order it will send an authorization request to the Issuer via a secure bank network.
5. 网关验证商户的签名证书以及商户是否签署了授权请求。接下来，它将获取账户信息和支付指令，并检查信息完整性和持卡人证书。如果一切正常，它将通过安全的银行网络向发卡机构发送授权请求。
6. The issuer returns the authorization.
6. 发卡机构返回授权。
7. The Acquirer's Gateway generates an authorization response which includes the gateway's certificate.
7. 收单机构网关生成包括网关证书的授权响应。
8. The Merchant checks the authorization response and completes the process by forwarding a purchase response to the Cardholder.
8. 商户检查授权响应，并通过向持卡人转发购买响应来完成流程。
9. The Merchant software authorizes the delivery of the purchased goods.
9. 商户软件授权交付购买的商品。
10. The Cardholder receives the purchased goods.
10. 持卡人收到购买的商品。
In the previous "single" domain case we already assume that there are multiple Cardholders, Merchants, Issuers and Acquirers. However all these parties belong to a single trust domain as there is only a single CCA, MCA and PCA. The trust relationship between multiple cardholders and multiple Issuers go via a single CCA in the same way as the trust relationship between an Acquirer and a Merchant uses the same MCA. The multi-domain case arises when there are multiple domains of CCA's, MCA's and PCA's. In SET these domains reside under a particular Geopolitical CA (GCA) which is illustrated in figure 18.
在前面的“单一”域名案例中，我们已经假设存在多个持卡人、商户、发卡机构和收单机构。然而，由于只有一个CCA、MCA和PCA，所有这些方都属于一个信任域。多个持卡人和多个发卡机构之间的信任关系通过一个CCA，就像收单机构和商户之间的信任关系使用相同的MCA一样。当存在CCA、MCA和PCA的多个域时，就会出现多域情况。在集合中，这些域位于特定的地缘政治CA（GCA）之下，如图18所示。
+-----------+
| Root CA |
| |
+-----------+
|
|
+----------------------|-------------------------------+
+-----------------------------------------------------+ |
| Brand CA | |
| |-+
+-----------------------------------------------------+
|
|
+----------------------|-------------------------------+
+-----------------------------------------------------+ |
| Geopolitical CA | |
| |-+
+-----------------------------------------------------+
| | |
| | |
+----|--------+ +---|-------+ +-------|----------+
+------------+ | +----------+ | +-----------------+ |
| Cardholder | | | Merchant | | | Payment Gateway | |
| CA |-+ | CA |-+ | CA |-+
+------------+ +----------+ +-----------------+
+-----------+
| 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可以代表一个国家或地区。该体系结构定义了管理和验证集合证书所需的信任层次结构，因为这些证书需要颁发、续订或吊销。每个地缘政治区域可能有不同的颁发、更新或撤销证书的政策。但是，一旦颁发了证书，属于不同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:
模型的建立包括四个步骤：
1. identification of the components that are involved and what they are called in this specific environment,
1. 识别所涉及的组件及其在该特定环境中的名称，
2. identification of the contractual relationships between the involved parties,
2. 确定相关方之间的合同关系，
3. identification of the relationships that are based on trust, and
3. 识别基于信任的关系，以及
4. consideration of the sequence of messages exchanged between components.
4. 考虑组件之间交换的消息序列。
We will consider the components of a distance learning environment in the context of the conceptual entities defined in [2].
我们将在（2）中定义的概念实体的上下文中考虑远程学习环境的组成部分。
- The Student (User) -- the person enrolling in a course (Service) and taking the corresponding exam.
- 学生（用户）——注册课程（服务）并参加相应考试的人。
- The Educator (Service Equipment) -- the education content server for which the content is delivered by the Professor.
- 教育家（服务设备）——教授为其交付内容的教育内容服务器。
- The Educator Authorization Module (Service Provider AAA Server). This module must check at the service access point whether the student complies with the requirements for enrolling in the course. The authorization may be based on both local (by the professor) and remote policies (originating from the faculty). Rules must allow enough flexibility to prevent students from being falsely denied access to courses. Strict rules must only be applied at graduation time.
- 教育者授权模块（服务提供商AAA服务器）。本模块必须在服务接入点检查学生是否符合课程注册要求。授权可能基于本地（由教授）和远程政策（由教员制定）。规则必须允许足够的灵活性，以防止学生被错误地拒绝参加课程。严格的规定只能在毕业时适用。
- The Faculty (Service Provider) -- the organization (department in U.S. terms) which controls the Service "Equipment" of which the Educator is one example.
- 教员（服务提供者）——控制服务“设备”的组织（美国术语中的系），教育家就是一个例子。
- The Curriculum Commission (Part of User Home Organization) -- body responsible for creating rules by which a student is allowed to enroll in a certain course and how this course will count toward his or her graduation requirements. Students may legally take any course available at any time, however the Curriculum Commission will decide whether this course will contribute towards their graduation. When a Student registers with a certain Educator, the Educator may check with the Curriculum Commission AAA server whether the course will count towards graduation and confirm this with the student.
- 课程委员会（用户家庭组织的一部分）——负责制定允许学生注册某一课程的规则以及该课程如何计入其毕业要求的机构。学生可以在任何时候合法地选修任何课程，但课程委员会将决定该课程是否有助于他们的毕业。当学生向某位教育者注册时，教育者可向课程委员会AAA服务器查询课程是否计入毕业，并与学生确认。
- The Student Administration (Part of User Home Organization) -- the administrative organization that authorizes students to enroll in courses if certain criteria, including financial criteria, are met. Next to the student, the Student Administration will keep track of any exam results for the student and will issue a graduation certificate when all criteria are met.
- 学生管理（用户主页组织的一部分）——如果满足某些标准，包括财务标准，则授权学生注册课程的管理组织。在学生旁边，学生管理部门将跟踪学生的任何考试结果，并在满足所有标准后颁发毕业证书。
Contractual relationships are illustrated in figure 19, below. Based on contract relationships,specific trust relationships are created as required.
合同关系如下图19所示。根据合同关系，根据需要创建特定的信任关系。
Although not shown in figure 19, it is assumed that the university has contractual relationships with the faculties in which every faculty is allowed and obligated to build, maintain and present one or more specific studies.
尽管图19中未显示，但假设大学与各学院之间存在合同关系，在合同关系中，每个学院都被允许并有义务建立、维护和呈现一项或多项具体研究。
+---------------------------------------------+
| +-----------------------------------------+ |
| | 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 |
+---------------------------------------------+
+---------------------------------------------+
| +-----------------------------------------+ |
| | 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
// = contractual relationship
** = trust relationship
Fig. 19 -- Contractual relationships - single domain case
图19——合同关系——单一领域案例
As shown in figure 19, the Student has a contractual relationship with the Faculty. The contract allows the Student to pursue a course of study consisting of a set of courses. Courses are presented to the Students by the Educators. A course of study may consist of courses from different Faculties.
如图19所示，学生与教师之间存在合同关系。合同允许学生学习由一系列课程组成的课程。课程由教育工作者向学生讲授。一门课程可能包括来自不同学院的课程。
Faculties have contracts among them allowing Students from one Faculty to enroll in courses from other Faculties.
各学院之间签订了合同，允许一个学院的学生注册其他学院的课程。
Faculties instantiate Educators based on a contract between the Faculty Administration and the professor implementing and managing the Educator. Authorization is based on policy rules defined by one or more parties in the contractual relationships. For example, a professor has a policy to give the course only in the afternoon and the Faculty has a policy to give the course to their own students and students from faculty-x but not, when oversubscribed, to faculty-y students.
教员根据教员管理部门和教授之间的合同实例化教育家，实施和管理教育家。授权基于合同关系中一方或多方定义的策略规则。例如，教授有只在下午授课的政策，教员有政策将课程授课给自己的学生和x系的学生，但在超额认购时，不会授课给y系的学生。
Figure 19 illustrates relevant trust relationships which statically enable AAA entities to communicate certain attributes in our simplified example. However, in order for the illustrated entities to work, other trust relationships that are not illustrated must already be in existence:
图19说明了相关的信任关系，在我们的简化示例中，这些关系静态地使AAA实体能够传递某些属性。然而，为了使所示实体工作，未示出的其他信任关系必须已经存在：
- A trust relationship based on a contract between the Faculty and the university enables a faculty to create and teach specific courses belonging to a course of study.
- 基于教员和大学之间合同的信任关系使教员能够创建和教授属于某一学习课程的特定课程。
- Although not further detailed in this example, it is worth noting that trust relationships between faculties authorize students from one faculty to enroll in courses with other faculties.
- 尽管在本例中没有进一步详细说明，但值得注意的是，各学院之间的信任关系授权一个学院的学生与其他学院一起注册课程。
- A professor responsible for the content of the Educator has a trust relationship with the administration of the faculty. Through this relationship, the faculty enables the professor to teach one or more courses fitting the requirements of the Curriculum Commission.
- 负责教育内容的教授与教员的管理部门有着信任关系。通过这种关系，教员使教授能够教授一门或多门符合课程委员会要求的课程。
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 |
+----------------------------------------------+
+----------------------------------------------+
| |
| +----------------+ 6 +----------------+ |
| | Student |----->| Curriculum | |
| | Administration |<-----| Commission | |
| | AAA Server | 5 | AAA Server | |
| +----------------+ _ +----------------+ |
| /|\ | /|/ |
| | | / / |
| 2,8| |3 / /6 |
| | | 4/ / |
| | | / / |
| | | / / |
| | \|/ /|/ |
| +---------------+ -- +---------------+ |
| | Educator A | | Educator B | |
| | AAA Server | | AAA Server | |
| +---------------+ +---------------+ |
| /|\ | |
|2,4,8| |3,6 |
+---------+ | | \|/ |
| | 1,7 | +---------------+ +---------------+ |
| Student |------->| Educator | | Educator | |
| |<-------| Course A | | Course B | |
| | 7,8 | +---------------+ +---------------+ |
+---------+ | Faculty |
+----------------------------------------------+
Fig. 20 -- AAA transactions - single domain case
图20——AAA交易——单域案例
1. After the Professor has set up the Service Equipment (Educator) students come to it presenting their ID (college card, name+faculty) and ask to be admitted to the course.
1. 教授设置好服务设备（教育家）后，学生出示身份证（大学证、姓名+教员）来到服务设备处，要求进入课程。
2. The Educator checks the ID to determine it is indeed dealing with a student from the faculty. This can include a check with the Student Administration.
2. 教育家检查ID以确定它确实在与来自教员的学生打交道。这可以包括与学生管理部门进行核对。
3. The Student Administration replies to the Educator AAA Server, and the Educator AAA Server replies to the Educator.
3. 学生管理答复教育者AAA服务器，教育者AAA服务器答复教育者。
4. The Educator checks the request of the Student against its own policy (courses only in the afternoon) and checks with the Curriculum Commission whether this student is advised to take the course. The necessary information is not normally known to or maintained by the professor.
4. 教育者根据自己的政策（只在下午上课）检查学生的要求，并向课程委员会检查是否建议该学生参加课程。教授通常不知道或不维护必要的信息。
5. The Curriculum Commission may check against the Student Administration to see if the Student had the necessary grades for the previous courses according to the policies set by the Curriculum Commission.
5. 课程委员会可根据课程委员会制定的政策，与学生管理部门进行核对，以确定该学生是否具备之前课程所需的成绩。
6. The Student Administration replies to the Curriculum Commission, the Curriculum Commission replies to the Educator AAA Server, and the Educator AAA Server replies to the Educator.
6. 学生管理部门回复课程委员会，课程委员会回复教育家AAA服务器，教育家AAA服务器回复教育家。
7. If now authorized, the Student is presented the material and the Student returns completed exams.
7. 如果现在获得授权，学生将收到材料，并返回已完成的考试。
8. If the Student passes the tests, the Educator informs both the Student and the Student Administration that the Student has passed.
8. 如果学生通过了考试，教育者会通知学生和学生管理部门该学生已经通过了考试。
We identify the following requirements for an AAA server environment for this example:
我们在此示例中确定了AAA服务器环境的以下要求：
1. It must be possible to delegate authority to contracted partners. Although this requirement is not explicit in the limited example, the relationship between University and Faculty may require delegation of authority regarding the curriculum to the Faculty. In the case of budget management, this requirement is evident.
1. 必须能够将权力委托给合同合作伙伴。虽然这一要求在有限的示例中没有明确，但大学与教员之间的关系可能需要将课程相关的权力委托给教员。就预算管理而言，这一要求是显而易见的。
2. A system to manage the delegated authority must be established. It is possible that this is just another AAA server environment. This comes from the fact that one partner requires the presence of specific rules to be in the AAA server of another partner. For example, the Faculty must be sure that certain checks are performed by the Educator's AAA server.
2. 必须建立管理委托权限的系统。这可能只是另一个AAA服务器环境。这是因为一个合作伙伴要求在另一个合作伙伴的AAA服务器中存在特定规则。例如，教员必须确保由教育者的AAA服务器执行某些检查。
3. AAA requests must either be evaluated at the AAA server queried or else parts of the request must be forwarded to another AAA server which can decide further on the request. As such, it must be possible to build a network of AAA servers in which each makes the decisions it is authorized to make by the relationships among the entities, e.g., a request from the Educator to the Curriculum Commission may result in a request to the Student Administration.
3. AAA请求必须在所查询的AAA服务器上进行评估，或者请求的一部分必须转发到另一个AAA服务器，该服务器可以进一步决定该请求。因此，必须能够构建一个AAA服务器网络，其中每个服务器根据实体之间的关系做出授权决策，例如，教育者向课程委员会提出的请求可能导致向学生管理部门提出的请求。
4. Transaction logs must be maintained to support non-repudiation for the grades of the students. This recording should be time-stamped and allow signing by authorized entities. A student should sign for taking an exam and this should be kept by the Educator's AAA
4. 必须维护事务日志，以支持学生成绩的不可否认性。该记录应加盖时间戳，并允许授权实体签字。学生应在参加考试时签名，并由教育者协会保存
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.
服务器评分后，教授应能够签署评分并将其发送给学生管理员，学生管理员的AAA服务器应记录此事件并为其添加时间戳。
5. Three types of AAA messages are required:
5. 需要三种类型的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.
合同关系——两个或多个商业实体之间建立的关系，其中条款和条件决定商品或服务的交换。
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.
动态信任关系——在两个可能从未有过任何先前关系的实体之间动态创建的安全关系。如果相关实体有相互信任的第三方，则可以创建此关系。示例：商户在支付交易时信任持卡人，因为信用卡组织知道他们两人。
Policy Decision Point (PDP) -- The point where policy decisions are made.
政策决策点（PDP）——作出政策决策的点。
Policy Enforcement Point (PEP) -- The point where the policy decisions are actually enforced.
策略执行点（PEP）——实际执行策略决策的点。
Resource Manager -- the component of an AAA Server which tracks the state of sessions associated with the AAA Server or its associated Service Equipment and provides an anchor point from which a session can be controlled, monitored, and coordinated.
资源管理器——AAA服务器的组件，它跟踪与AAA服务器或其相关服务设备相关的会话状态，并提供一个锚定点，从该锚定点可以控制、监视和协调会话。
Roaming -- An authorization transaction in which the Service Provider and the User Home Organization are two different organizations. (Note that the dialin application is one for which roaming has been actively considered, but this definition encompasses other applications as well.)
漫游——一种授权事务，其中服务提供商和用户总部组织是两个不同的组织。（请注意，拨号应用程序是一个已积极考虑漫游的应用程序，但此定义也包括其他应用程序。）
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.
静态信任关系——由受信任方创建的两个实体之间预先建立的安全关系。这种关系有助于AAA消息的交换，具有一定的安全性和可跟踪性。示例：有权访问接线柜的网络运营商（受信任方）在用户的墙上插座和特定网络端口之间创建连接。用户在一定程度上被信任连接到这个特定的网络端口。
User -- the entity seeking authorization to use a resource or a service.
用户——寻求使用资源或服务的授权的实体。
User Home Organization (UHO) -- An organization with whom the User has a contractual relationship which can authenticate the User and may be able to authorize access to resources or services.
用户总部组织（UHO）——用户与之有合同关系的组织，可以对用户进行身份验证，并且可以授权访问资源或服务。
References
工具书类
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[2] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Framework", RFC 2904, August 2000.
[2] Vollbrecht，J.，Calhoun，P.，Farrell，S.，Gommans，L.，Gross，G.，de Bruijn，B.，de Laat，C.，Holdrege，M.和D.Spence，“AAA授权框架”，RFC 29042000年8月。
[3] Farrell, S., Vollbrecht, J., Calhoun, P., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Requirements", RFC 2906, August 2000.
[3] Farrell，S.，Vollbrecht，J.，Calhoun，P.，Gommans，L.，Gross，G.，de Bruijn，B.，de Laat，C.，Holdrege，M.和D.Spence，“AAA授权要求”，RFC 2906，2000年8月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[5] Aboba，B.和G.Zorn，“评估漫游协议的标准”，RFC 2477，1999年1月。
[6] Beadles, Mark Anthony, and David Mitton, "Criteria for Evaluating Network Access Server Protocols", Work in Progress.
[6] Beadles、Mark Anthony和David Mitton，“评估网络访问服务器协议的标准”，正在进行中。
[7] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[7] Aboba，B.和M.Beadles，“网络接入标识符”，RFC 2486，1999年1月。
[8] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[8] Rigney，C.，Rubens，A.，Simpson，W.和S.Willens，“远程认证拨入用户服务（RADIUS）”，RFC 21381997年4月。
[9] Calhoun, P. and G. Zorn, "Roamops Authentication/Authorization Requirements", Work in Progress.
[9] Calhoun，P.和G.Zorn，“Roamops认证/授权要求”，正在进行中。
[10] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[10] Perkins，C.，“IP移动支持”，RFC 2002，1996年10月。
[11] Glass, Steven, et al, "Mobile IP Authentication, Authorization, and Accounting Requirements", Work in Progress.
[11] Glass，Steven等人，“移动IP认证、授权和记帐要求”，正在进行中。
[12] Hiller, Tom, et al., "cdma2000 Wireless Data Requirements for AAA", Work in Progress.
[12] Hiller，Tom等，“AAA的cdma2000无线数据要求”，正在进行中。
[13] Neilson, Rob, Jeff Wheeler, Francis Reichmeyer, and Susan Hares, "A Discussion of Bandwidth Broker Requirements for Internet2 Qbone Deployment", ver. 0.7, August 1999, http://www.merit.edu/working.groups/i2-qbone-bb/doc/BB_Req7.pdf.
[13] Neilson、Rob、Jeff Wheeler、Francis Reichmeyer和Susan Hares，“Internet2 Qbone部署的带宽代理要求讨论”，第。一九九九年八月七日，http://www.merit.edu/working.groups/i2-qbone-bb/doc/BB_Req7.pdf.
[14] deBry, R., "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999.
[14] deBry，R.，“互联网打印协议/1.0：模型和语义”，RFC2566，1999年4月。
[15] Burdett, D., "Internet Open Trading Protocol - IOTP", RFC 2801, April 2000.
[15] Burdett，D.，“互联网开放交易协议-IOTP”，RFC 28012000年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] “SET安全电子交易规范第1册：业务描述”，版本1.0，1997年5月31日，http://www.setco.org/download/set_bk1.pdf.
Authors' Addresses
作者地址
John R. Vollbrecht Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA
John R.Vollbrecht Interlink Networks，Inc.美国密歇根州安阿伯市科技大道775号200室，邮编：48108
Phone: +1 734 821 1205
Fax: +1 734 821 1235
EMail: jrv@interlinknetworks.com
Phone: +1 734 821 1205
Fax: +1 734 821 1235
EMail: jrv@interlinknetworks.com
Pat R. Calhoun Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA
Pat R.Calhoun网络和安全研究中心，太阳实验室太阳微系统公司，美国加利福尼亚州门罗公园网络圈15号，邮编94025
Phone: +1 650 786 7733
Fax: +1 650 786 6445
EMail: pcalhoun@eng.sun.com
Phone: +1 650 786 7733
Fax: +1 650 786 6445
EMail: pcalhoun@eng.sun.com
Stephen Farrell Baltimore Technologies 61 Fitzwilliam Lane Dublin 2 Ireland
Stephen Farrell Baltimore Technologies 61 Fitzwilliam Lane Dublin 2爱尔兰
Phone: +353 1 647 7406
Fax: +353 1 647 7499
EMail: stephen.farrell@baltimore.ie
Phone: +353 1 647 7406
Fax: +353 1 647 7499
EMail: stephen.farrell@baltimore.ie
Leon Gommans Enterasys Networks EMEA Kerkplein 24 2841 XM Moordrecht The Netherlands
Leon Gommans Enterasys Networks EMEA Kerkplein 24 2841 XM Moordrecht荷兰
Phone: +31 182 379279
email: gommans@cabletron.com
or at University of Utrecht:
l.h.m.gommans@phys.uu.nl
Phone: +31 182 379279
email: gommans@cabletron.com
or at University of Utrecht:
l.h.m.gommans@phys.uu.nl
George M. Gross Lucent Technologies 184 Liberty Corner Road, m.s. LC2N-D13 Warren, NJ 07059 USA
美国新泽西州沃伦市自由角路184号乔治·M·格罗斯朗讯科技公司LC2N-D13 07059
Phone: +1 908 580 4589
Fax: +1 908-580-4991
EMail: gmgross@lucent.com
Phone: +1 908 580 4589
Fax: +1 908-580-4991
EMail: gmgross@lucent.com
Betty de Bruijn Interpay Nederland B.V. Eendrachtlaan 315 3526 LB Utrecht The Netherlands
Betty de Bruijn Interpay Nederland B.V.Eendractlaan 315 3526磅荷兰乌得勒支
Phone: +31 30 2835104
EMail: betty@euronet.nl
Phone: +31 30 2835104
EMail: betty@euronet.nl
Cees T.A.M. de Laat Physics and Astronomy dept. Utrecht University Pincetonplein 5, 3584CC Utrecht Netherlands
荷兰乌得勒支大学平克顿普莱因5号物理与天文系，邮编3584CC
Phone: +31 30 2534585
Phone: +31 30 2537555
EMail: delaat@phys.uu.nl
Phone: +31 30 2534585
Phone: +31 30 2537555
EMail: delaat@phys.uu.nl
Matt Holdrege ipVerse 223 Ximeno Ave. Long Beach, CA 90803
Matt Holdrege ipVerse加利福尼亚州长滩西门诺大道223号，邮编90803
EMail: matt@ipverse.com
EMail: matt@ipverse.com
David W. Spence Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA
David W.Spence Interlink Networks，Inc.美国密歇根州安阿伯市科技大道775号200室，邮编：48108
Phone: +1 734 821 1203
Fax: +1 734 821 1235
EMail: dspence@interlinknetworks.com
Phone: +1 734 821 1203
Fax: +1 734 821 1235
EMail: dspence@interlinknetworks.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（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编辑功能的资金目前由互联网协会提供。