Network Working Group J. Vollbrecht
Request for Comments: 2904 Interlink Networks, Inc.
Category: Informational P. Calhoun
Sun Microsystems, Inc.
S. Farrell
Baltimore Technologies
L. Gommans
Enterasys Networks EMEA
G. Gross
Lucent Technologies
B. de Bruijn
Interpay Nederland B.V.
C. de Laat
Utrecht University
M. Holdrege
ipVerse
D. Spence
Interlink Networks, Inc.
August 2000
Network Working Group J. Vollbrecht
Request for Comments: 2904 Interlink Networks, Inc.
Category: Informational P. Calhoun
Sun Microsystems, Inc.
S. Farrell
Baltimore Technologies
L. Gommans
Enterasys Networks EMEA
G. Gross
Lucent Technologies
B. de Bruijn
Interpay Nederland B.V.
C. de Laat
Utrecht University
M. Holdrege
ipVerse
D. Spence
Interlink Networks, Inc.
August 2000
AAA Authorization Framework
AAA授权框架
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This memo serves as the base requirements for Authorization of Internet Resources and Services (AIRS). It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols.
本备忘录作为互联网资源和服务（AIRS）授权的基本要求。它提供了一个体系结构框架，用于理解Internet资源和服务的授权，并导出了授权协议的要求。
Table of Contents
目录
1. Introduction ................................................ 2
2. Authorization Entities and Trust Relationships .............. 4
3. Message Sequences ........................................... 7
3.1. Single Domain Case ..................................... 7
3.1.1. The Agent Sequence .............................. 7
3.1.2. The Pull Sequence ............................... 8
3.1.3. The Push Sequence ............................... 9
3.2. Roaming ................................................ 10
3.3. Distributed Services ................................... 13
3.4. Combining Roaming and Distributed Services ............. 15
4. Relationship of Authorization and Policy .................... 16
4.1. Policy Retrieval ....................................... 16
4.2. Policy Evaluation ...................................... 17
4.3. Policy Enforcement ..................................... 17
4.4. Distributed Policy ..................................... 18
5. Use of Attribute Certificates ............................... 19
6. Resource Management ......................................... 22
6.1. Session Management ..................................... 23
6.2. The Resource Manager ................................... 24
7. AAA Message Forwarding and Delivery ......................... 25
8. End-to-End Security ......................................... 26
9. Streamlined Authorization Process ........................... 27
10. Summary of the Authorization Framework ..................... 28
11. Security Considerations .................................... 28
Glossary ....................................................... 29
References ..................................................... 31
Authors' Addresses ............................................. 32
Full Copyright Statement ....................................... 35
1. Introduction ................................................ 2
2. Authorization Entities and Trust Relationships .............. 4
3. Message Sequences ........................................... 7
3.1. Single Domain Case ..................................... 7
3.1.1. The Agent Sequence .............................. 7
3.1.2. The Pull Sequence ............................... 8
3.1.3. The Push Sequence ............................... 9
3.2. Roaming ................................................ 10
3.3. Distributed Services ................................... 13
3.4. Combining Roaming and Distributed Services ............. 15
4. Relationship of Authorization and Policy .................... 16
4.1. Policy Retrieval ....................................... 16
4.2. Policy Evaluation ...................................... 17
4.3. Policy Enforcement ..................................... 17
4.4. Distributed Policy ..................................... 18
5. Use of Attribute Certificates ............................... 19
6. Resource Management ......................................... 22
6.1. Session Management ..................................... 23
6.2. The Resource Manager ................................... 24
7. AAA Message Forwarding and Delivery ......................... 25
8. End-to-End Security ......................................... 26
9. Streamlined Authorization Process ........................... 27
10. Summary of the Authorization Framework ..................... 28
11. Security Considerations .................................... 28
Glossary ....................................................... 29
References ..................................................... 31
Authors' Addresses ............................................. 32
Full Copyright Statement ....................................... 35
This document is one of a series of three documents under consideration by the AAAarch RG dealing with the authorization requirements for AAA protocols. The three documents are:
本文件是AAAarch RG正在考虑的涉及AAA协议授权要求的三个系列文件之一。这三份文件是：
AAA Authorization Framework (this document) AAA Authorization Requirements [2] AAA Authorization Application Examples [3]
AAA授权框架（本文件）AAA授权要求[2]AAA授权应用示例[3]
There is a demonstrated need for a common scheme which covers all Internet services which offer Authorization. This common scheme will address various functional architectures which meet the requirements of basic services. We attempt to describe these architectures and functions as a basis for deriving requirements for an authorization protocol [2].
事实证明，需要一个涵盖所有提供授权的互联网服务的通用方案。该通用方案将解决满足基本服务需求的各种功能架构。我们试图将这些体系结构和功能描述为导出授权协议需求的基础[2]。
These architectures include Policy structures, Certificate Authorities, Resource Managers, Inter-Domain and Multi-Domain schemes, and Distributed Services. The requirements are for the expected use of Authorization services across these architectures.
这些体系结构包括策略结构、证书颁发机构、资源管理器、域间和多域方案以及分布式服务。这些要求是针对这些体系结构中授权服务的预期使用。
A representative set of applications that may use this architecture to support their authorization needs is presented in [3]. The examples in [3] show how this framework may be used to meet a wide variety of different authorization needs.
[3]中介绍了一组具有代表性的应用程序，这些应用程序可能使用此体系结构来支持其授权需求。[3]中的示例展示了如何使用该框架来满足各种不同的授权需求。
We expect that this work may be extended in the future to a more comprehensive model and that the scheme described here will be incorporated into a framework that includes authentication, accounting and auditing. We have referenced a number of authorization sources, but also recognize that there may be some that we have missed and that should be included. Please notify one of the authors of any such oversight so it can be corrected in a future revision.
我们希望，这项工作在未来可能会扩展到一个更全面的模型，并且这里描述的方案将被纳入一个包括身份验证、会计和审计的框架中。我们参考了许多授权来源，但也认识到可能有一些我们遗漏了，应该包括在内。请将任何此类疏忽告知其中一位作者，以便在将来的修订中予以纠正。
In general, it is assumed that the parties who are participating in the authorization process have already gone through an authentication phase. The authentication method used by those parties is outside the scope of this document except to the extent that it influences the requirements found in a subsequent authorization process. Likewise, accounting requirements are outside the scope of this document other than recording accounting data or establishing trust relationships during an authorization that will facilitate a subsequent accounting phase.
一般来说，假设参与授权过程的各方已经经历了身份验证阶段。双方使用的认证方法不在本文件范围内，除非其影响后续授权过程中的要求。同样，除了在授权期间记录会计数据或建立信任关系以促进后续会计阶段外，会计要求不在本文件范围内。
The work for this memo was done by a group that originally was the Authorization subgroup of the AAA Working Group of the IETF. When the charter of the AAA working group was changed to focus on MobileIP and NAS requirements, the AAAarch Research Group was chartered within the IRTF to continue and expand the architectural work started by the Authorization subgroup. This memo is one of four which were created by the subgroup. This memo is a starting point for further work within the AAAarch Research Group. It is still a work in progress and is published so that the work will be available for the AAAarch subgroup and others working in this area, not as a definitive description of architecture or requirements.
本备忘录的工作由一个小组完成，该小组最初是IETF AAA工作组的授权小组。当AAA工作组章程更改为侧重于MobileIP和NAS需求时，AAAarch研究组在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]中所述的方式使用术语“必须”、“应该”和“可能”及其否定词。
The following framework is being presented in order to provide a framework for discussing authorization requirements for a large number of applications. The intent is to provide some common vocabulary for the discussion. Terminology is introduced for basic elements in the authorization transaction and for concepts that appear to be common to all (or at least many) authorization proposals.
下面的框架是为了提供一个框架来讨论大量应用程序的授权需求。目的是为讨论提供一些常用词汇。为授权事务中的基本元素以及所有（或至少许多）授权提案中常见的概念引入了术语。
Figure 1, below, identifies the basic conceptual entities that may be participants in an authorization:
下图1确定了可能参与授权的基本概念实体：
1. A User who wants access to a service or resource.
1. 希望访问服务或资源的用户。
2. A User Home Organization (UHO) that has an agreement with the user and checks whether the user is allowed to obtain the requested service or resource. This entity may carry information required to authorize the User, which might not be known to the Service Provider (such as a credit limit).
2. 与用户有协议并检查是否允许用户获得请求的服务或资源的用户主组织（UHO）。该实体可能携带授权用户所需的信息，服务提供商可能不知道这些信息（例如信用额度）。
3. A Service Provider's AAA Server which authorizes a service based on an agreement with the User Home Organization without specific knowledge about the individual User. This agreement may contain elements that are not relevant to an individual user (e.g., the total agreed bandwidth between the User Home Organization and the Service Provider).
3. 一种服务提供商的AAA服务器，它根据与用户主组织的协议授权服务，而不需要具体了解单个用户。该协议可能包含与单个用户无关的元素（例如，用户归属组织和服务提供商之间的总约定带宽）。
4. A Service Provider's Service Equipment which provides the service itself. This might, for example, be a NAS in dial service, or a Router in the QoS service, or a print server in the Internet Printing service.
4. 服务提供商提供服务的服务设备。例如，这可能是拨号服务中的NAS，或QoS服务中的路由器，或Internet打印服务中的打印服务器。
+------+ +-------------------------+
| | | User Home Organization |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| |
| |
| |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
+------+ +-------------------------+
| | | User Home Organization |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| |
| |
| |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 1 -- The Basic Authorization Entities
图1——基本授权实体
These entities will be referenced in the authorization requirements.
这些实体将在授权要求中引用。
There may be bilateral agreements between pairs of organizations involved in an authorization transaction. Agreements between organizations may take the form of formal contracts or Service Level Agreements. Figure 2 uses double lines to show relationships that may exist between the User and the User Home Organization and between the User Home Organization and the Service Provider.
参与授权交易的组织对之间可能存在双边协议。组织之间的协议可以采取正式合同或服务级别协议的形式。图2使用双线显示用户和用户主组织之间以及用户主组织和服务提供商之间可能存在的关系。
+------+ +-------------------------+
| | | User Home Organization |
| |======| +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| | ||
| | ||
| | ||
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
+------+ +-------------------------+
| | | User Home Organization |
| |======| +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| | ||
| | ||
| | ||
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 2 -- Service Agreements
图2——服务协议
Authorization is based on these bilateral agreements between entities. Agreements may be chained, as shown in figure 2. The User has an agreement with the User Home Organization (e.g., the User may have access to the service between 9:00 a.m. and 11:00 a.m. daily). The User Home Organization has an agreement with the Service Provider (e.g., that all requests for access will be granted, except between 5:00 a.m. and 10:00 a.m. on Sunday). The fulfillment of the User's request depends on both agreements being honored.
授权基于实体之间的这些双边协议。协议可以链接，如图2所示。用户与用户所在组织有协议（例如，用户可以在每天上午9:00到11:00之间访问服务）。用户总部组织与服务提供商达成协议（例如，除周日上午5:00至10:00之间的访问请求外，所有访问请求都将被批准）。用户请求的实现取决于两个协议是否得到遵守。
Note that these agreements may be implemented by hand configuration or by evaluation of Policy data stored in a Policy database. The point is that there must be a set of known rules in place between entities in order for authorization transactions to be executed.
请注意，这些协议可以通过手动配置或通过评估存储在策略数据库中的策略数据来实现。要点是，为了执行授权事务，实体之间必须有一组已知的规则。
Trust is necessary to allow each entity to "know" that the policy it is authorizing is correct. This is a business issue as well as a protocol issue. Trust is often established through third party authentication servers (such as Kerberos), via a certificate authority, by configuring shared secrets or passwords, or by sharing a common facility (such as a connecting wire between processors). These "static" trust relationships are necessary for authorization
信任是必要的，以允许每个实体“知道”其授权的策略是正确的。这是一个业务问题，也是一个协议问题。信任通常是通过第三方身份验证服务器（如Kerberos）、通过证书颁发机构、通过配置共享机密或密码或通过共享公共设施（如处理器之间的连接线）建立的。这些“静态”信任关系是授权所必需的
transactions to take place. Static trust relationships are used in an authorization sequence to establish a "dynamic" relationship between the User and the Service Equipment. Several possible authorization sequences are possible, each of which use the static trust "chain" to have the user first be approved by the User Home Organization, and then have the Service Provider accept the request based on its trust of the User Home Organization.
要进行的交易。静态信任关系用于授权序列中，以在用户和服务设备之间建立“动态”关系。几个可能的授权序列是可能的，每个都使用静态信任“链”让用户首先得到用户主组织的批准，然后让服务提供商基于其对用户主组织的信任来接受请求。
In general, the User Home Organization and the Service Provider are different entities or different "administrative domains". In the simplest case, however, the User Home Organization and the Service Provider may be combined as a single entity. This case will be used to describe three authorization sequences possible with the simple case.
通常，用户总部组织和服务提供商是不同的实体或不同的“管理域”。然而，在最简单的情况下，用户归属组织和服务提供商可以组合为单个实体。本案例将用于描述简单案例中可能出现的三种授权序列。
In following sections these concepts will be applied to more complicated cases involving separate User Home Organization and Service Provider entities (as in roaming) and multiple Service Providers each with their own AAA Servers and Service Equipment (as in distributed services).
在以下章节中，这些概念将应用于更复杂的情况，这些情况涉及单独的用户归属组织和服务提供商实体（如漫游）以及多个服务提供商，每个服务提供商都有自己的AAA服务器和服务设备（如分布式服务）。
This case includes the User, the Service Provider's AAA Server, and the Service Provider's Service Equipment. Examples of this case include a NAS supported by a standalone RADIUS server, or a QoS Router supported by a local bandwidth broker.
此案例包括用户、服务提供商的AAA服务器和服务提供商的服务设备。这种情况的示例包括独立RADIUS服务器支持的NAS，或本地带宽代理支持的QoS路由器。
The sequences considered in the following figures are the "agent", "pull", and "push" sequences for the single domain case.
下图中考虑的序列是单域情况下的“代理”、“拉”和“推”序列。
In the agent sequence (see figure 3), the Service Provider AAA Server functions as an agent between the User and the service itself. The AAA Server receives a request from the User and forwards authorization and possibly configuration information to the Service Equipment. In this model, the User sends a request to the Service Provider's AAA Server (1), which will apply a policy associated with the User and the particular service being requested. The AAA Server sends a request to the Service Equipment, and the Service Equipment sets up whatever is requested (2). The Service Equipment then responds to the AAA Server acknowledging that it has set up the Service for the user (3). The AAA Server replies to the User telling it that the Service is set up (4).
在代理序列中（参见图3），服务提供者AAA服务器充当用户和服务本身之间的代理。AAA服务器接收来自用户的请求，并将授权和可能的配置信息转发给服务设备。在此模型中，用户向服务提供商的AAA服务器（1）发送请求，该服务器将应用与用户和所请求的特定服务相关联的策略。AAA服务器向服务设备发送请求，服务设备设置任何请求（2）。然后，服务设备响应AAA服务器，确认其已为用户设置了服务（3）。AAA服务器回复用户，告知其服务已设置（4）。
Depending on the nature of the service, further communication may take place between the User and the Service Equipment. For this to occur, there needs to be a binding between the User and the authorized service. This requires further study.
根据服务的性质，用户和服务设备之间可能发生进一步的通信。要实现这一点，用户和授权服务之间需要有一个绑定。这需要进一步研究。
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 4 | +-------------------+ |
| User | | | /|\ |
| | | |2 |3 |
| | | \|/ | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
+------+ | |
+-------------------------+
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 4 | +-------------------+ |
| User | | | /|\ |
| | | |2 |3 |
| | | \|/ | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
+------+ | |
+-------------------------+
Fig. 3 -- Agent Sequence
图3——代理序列
Example: A regular user may ask for 1 Mb/s bandwidth (1). The bandwidth broker (AAA Server) tells the router (Service Equipment) to set this user into the 1Mb/s "queue" (2). The router responds that it has done so (3), and the bandwidth broker tells the User the bandwidth is set up (4).
示例：普通用户可能要求1 Mb/s带宽（1）。带宽代理（AAA服务器）告诉路由器（服务设备）将该用户设置为1Mb/s“队列”（2）。路由器响应它已经这样做了（3），带宽代理告诉用户带宽已设置（4）。
The pull sequence (figure 4) is what is typically used in the Dialin application, in the Mobile-IP proposal, and in some QoS proposals. The User sends a request to the Service Equipment (1), which forwards it to the Service Provider's AAA Server (2), which evaluates the request and returns an appropriate response to the Service Equipment (3), which sets up the service and tells the User it is ready (4).
拉取序列（图4）通常用于拨号应用程序、移动IP方案和一些QoS方案中。用户向服务设备（1）发送请求，服务设备（1）将请求转发给服务提供商的AAA服务器（2），服务提供商的AAA服务器评估请求并向服务设备（3）返回适当的响应，服务设备（3）设置服务并告知用户其已准备就绪（4）。
+-------------------------+
+------+ | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| User | | /|\ | |
| | | |2 |3 |
| | | | \|/ |
| | 1 | +-------------------+ |
| |------+->| Service | |
| |<-----+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
+-------------------------+
+------+ | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| User | | /|\ | |
| | | |2 |3 |
| | | | \|/ |
| | 1 | +-------------------+ |
| |------+->| Service | |
| |<-----+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
Fig. 4 -- Pull Sequence
图4——拉动顺序
The push sequence (figure 5) requires that the User get from the Service Provider's AAA Server a ticket or certificate verifying that it is o.k. for the User to have access to the service (1,2). The User includes the ticket in the request (3) to the Service Equipment. The Service Equipment uses the ticket to verify that the request is approved by the Service Provider's AAA Server. The Service Equipment then sends an o.k. to the User (4).
推送序列（图5）要求用户从服务提供商的AAA服务器获得一张票证或证书，以验证用户是否可以访问服务（1,2）。用户在对服务设备的请求（3）中包括票据。服务设备使用票据验证请求是否已被服务提供商的AAA服务器批准。然后，服务设备向用户（4）发送确认。
The ticket the user gets from the Service Provider's AAA Server will typically have some time limit on it. It may contain an indication of service location, and in some applications, it might be used for more than one request.
用户从服务提供商的AAA服务器获得的票证通常会有一些时间限制。它可能包含服务位置的指示，在某些应用程序中，它可能用于多个请求。
In the push sequence the communication between the AAA Server and the Service Equipment is relayed through the User rather than directly between themselves.
在推送序列中，AAA服务器和服务设备之间的通信通过用户中继，而不是直接在它们之间中继。
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 2 | +-------------------+ |
| User | | |
| | | |
| | | |
| | 3 | +-------------------+ |
| |------+->| Service | |
| |<-----+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 2 | +-------------------+ |
| User | | |
| | | |
| | | |
| | 3 | +-------------------+ |
| |------+->| Service | |
| |<-----+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
Fig. 5 -- Push Sequence
图5——推送序列
In many interesting situations, the organization that authorizes and authenticates the User is different from the organization providing the service. This situation has been explored in the Roaming Operations (roamops) Working Group. For purposes of this discussion, any situation in which the User Home Organization is different from the Service Provider is considered to be roaming.
在许多有趣的情况下，授权和验证用户的组织与提供服务的组织不同。漫游操作（roamops）工作组已经探讨了这种情况。出于本讨论的目的，将用户归属组织不同于服务提供商的任何情况视为漫游。
Examples of roaming include an ISP selling dialin ports to other organizations or a Mobile-IP provider allowing access to a user from another domain.
漫游的示例包括ISP向其他组织出售拨号端口，或允许用户从其他域访问的移动IP提供商。
The same agent, pull and push sequences are possible with roaming. If the Service Provider's AAA Server and the Service Equipment are grouped as a logical entity for purposes of description, then the following figures illustrate these cases.
漫游时可以使用相同的代理、拉和推序列。如果出于描述目的，服务提供商的AAA服务器和服务设备被分组为一个逻辑实体，则下图说明了这些情况。
+------+ +-------------------------+
| | 1 | User Home Organization |
| |----->| +-------------------+ |
| | | | AAA Server | |
| |<-----| | | |
| | 4 | +-------------------+ |
| | | |
| | +-------------------------+
| | | /|\
| | |2 |3
| | \|/ |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
+------+ +-------------------------+
| | 1 | User Home Organization |
| |----->| +-------------------+ |
| | | | AAA Server | |
| |<-----| | | |
| | 4 | +-------------------+ |
| | | |
| | +-------------------------+
| | | /|\
| | |2 |3
| | \|/ |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 6 -- Roaming Agent Sequence
图6——漫游代理程序序列
+------+ +-------------------------+
| | | User Home Organization |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| | /|\ |
| | |2 |3
| | | \|/
| | +-------------------------+
| | | Service Provider |
| User | | +-------------------+ |
| | | | AAA Server | |
| | 1 | | | |
| |----->| +-------------------+ |
| | | |
| |<-----| +-------------------+ |
| | 4 | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
+------+ +-------------------------+
| | | User Home Organization |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| | /|\ |
| | |2 |3
| | | \|/
| | +-------------------------+
| | | Service Provider |
| User | | +-------------------+ |
| | | | AAA Server | |
| | 1 | | | |
| |----->| +-------------------+ |
| | | |
| |<-----| +-------------------+ |
| | 4 | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 7 -- Roaming Pull Sequence
图7——漫游拉取序列
+------+ +-------------------------+
| | 1 | User Home Organization |
| |----->| +-------------------+ |
| | | | AAA Server | |
| |<-----| | | |
| | 2 | +-------------------+ |
| | | |
| | +-------------------------+
| |
| |
| |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | 3 | | | |
| |----->| +-------------------+ |
| | | |
| |<-----| +-------------------+ |
| | 4 | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
+------+ +-------------------------+
| | 1 | User Home Organization |
| |----->| +-------------------+ |
| | | | AAA Server | |
| |<-----| | | |
| | 2 | +-------------------+ |
| | | |
| | +-------------------------+
| |
| |
| |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | 3 | | | |
| |----->| +-------------------+ |
| | | |
| |<-----| +-------------------+ |
| | 4 | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 8 -- Roaming Push Sequence
图8——漫游推送序列
To provide a complete service to a user, offerings from several service providers may need to be combined. An example would be a user who requires a QoS service for a session that crosses multiple ISPs. Any service that is provided by more than one Service Provider acting in concert is a distributed service. Figure 9 illustrates distributed services.
为了向用户提供完整的服务，可能需要将多个服务提供商提供的服务组合起来。例如，对于跨多个ISP的会话，需要QoS服务的用户。由多个一致行动的服务提供商提供的任何服务都是分布式服务。图9展示了分布式服务。
+-------------------+ +-------------------+
+------+ | Org1 | | Org2 |
| | | +-------------+ | | +-------------+ |
| | | | AAA Server | | | | AAA Server | |
| | | | | | | | | |
| | | +-------------+ | | +-------------+ |
| User |======| |======| |
| | | +-------------+ | | +-------------+ |
| | | | Service | | | | Service | |
| | | | Equipment | | | | Equipment | |
| | | +-------------+ | | +-------------+ |
+------+ | | | |
+-------------------+ +-------------------+
+-------------------+ +-------------------+
+------+ | Org1 | | Org2 |
| | | +-------------+ | | +-------------+ |
| | | | AAA Server | | | | AAA Server | |
| | | | | | | | | |
| | | +-------------+ | | +-------------+ |
| User |======| |======| |
| | | +-------------+ | | +-------------+ |
| | | | Service | | | | Service | |
| | | | Equipment | | | | Equipment | |
| | | +-------------+ | | +-------------+ |
+------+ | | | |
+-------------------+ +-------------------+
Fig. 9 -- Distributed Services
图9——分布式服务
The agreements between entities in figure 9 imply that the request from the User will be authenticated and authorized by the first organization, then forwarded to the second organization. Note that the sequence between User and Org1 may be different than between Org1 and Org2. The first might use a pull sequence, and the second might use an agent sequence. This example is illustrated in figure 10.
图9中实体之间的协议意味着来自用户的请求将由第一个组织进行身份验证和授权，然后转发给第二个组织。请注意，用户和Org1之间的顺序可能不同于Org1和Org2之间的顺序。第一个可能使用拉序列，第二个可能使用代理序列。该示例如图10所示。
+-------------------+ +-------------------+
+------+ | Org1 | | Org2 |
| | | +-------------+ | 3 | +-------------+ |
| | | | AAA Server |--+------+->| AAA Server | |
| | | | |<-+------+--| | |
| | | +-------------+ | 6 | +-------------+ |
| User | | /|\ | | | | /|\ |
| | | |2 |7 | | |4 |5 |
| | | | \|/ | | \|/ | |
| | 1 | +-------------+ | | +-------------+ |
| |------+->| Service | | | | Service | |
| |<-----+--| Equipment | | | | Equipment | |
| | 8 | +-------------+ | | +-------------+ |
+------+ | | | |
+-------------------+ +-------------------+
+-------------------+ +-------------------+
+------+ | Org1 | | Org2 |
| | | +-------------+ | 3 | +-------------+ |
| | | | AAA Server |--+------+->| AAA Server | |
| | | | |<-+------+--| | |
| | | +-------------+ | 6 | +-------------+ |
| User | | /|\ | | | | /|\ |
| | | |2 |7 | | |4 |5 |
| | | | \|/ | | \|/ | |
| | 1 | +-------------+ | | +-------------+ |
| |------+->| Service | | | | Service | |
| |<-----+--| Equipment | | | | Equipment | |
| | 8 | +-------------+ | | +-------------+ |
+------+ | | | |
+-------------------+ +-------------------+
Fig. 10 -- A Possible Distributed Sequence
图10——可能的分布式序列
There are a number of other ways that authorization sequences for distributed services can be set up. For example, it is possible that, in order to reduce delay time in setting up a session, Org1 could send a response to the user before receiving a verification that Org2 has authorized the service. In that case Org1 would need to be able to revoke the authorization sent earlier if Org2 does not send the authorization in some amount of time.
有许多其他方法可以设置分布式服务的授权序列。例如，为了减少建立会话的延迟时间，Org1可能在接收到Org2已授权服务的验证之前向用户发送响应。在这种情况下，如果Org2在一段时间内没有发送授权，Org1需要能够撤销先前发送的授权。
Figure 11 shows a combination of Roaming and Distributed Services. Contract and trust relationships may be set up in number of ways, depending on a variety of factors, especially the business model.
图11显示了漫游和分布式服务的组合。合同和信任关系可以通过多种方式建立，这取决于各种因素，尤其是商业模式。
+------+ +-------------------+ +-------------------+
| | | User Home Org | | SuperOrg |
| | | +-------------+ | | +-------------+ |
| | | | AAA Server | | | | AAA Server | |
| | | | | | | | | |
| | | +-------------+ | | +-------------+ |
| | | | | |
| | +-------------------+ +-------------------+
| |
| |
| | +-------------------+ +-------------------+
| User | | Org1 | | Org2 |
| | | +-------------+ | | +-------------+ |
| | | | AAA Server | | | | AAA Server | |
| | | | | | | | | |
| | | +-------------+ | | +-------------+ |
| | | | | |
| | | +-------------+ | | +-------------+ |
| | | | Service | | | | Service | |
| | | | Equipment | | | | Equipment | |
| | | +-------------+ | | +-------------+ |
| | | | | |
+------+ +-------------------+ +-------------------+
+------+ +-------------------+ +-------------------+
| | | User Home Org | | SuperOrg |
| | | +-------------+ | | +-------------+ |
| | | | AAA Server | | | | AAA Server | |
| | | | | | | | | |
| | | +-------------+ | | +-------------+ |
| | | | | |
| | +-------------------+ +-------------------+
| |
| |
| | +-------------------+ +-------------------+
| User | | Org1 | | Org2 |
| | | +-------------+ | | +-------------+ |
| | | | AAA Server | | | | AAA Server | |
| | | | | | | | | |
| | | +-------------+ | | +-------------+ |
| | | | | |
| | | +-------------+ | | +-------------+ |
| | | | Service | | | | Service | |
| | | | Equipment | | | | Equipment | |
| | | +-------------+ | | +-------------+ |
| | | | | |
+------+ +-------------------+ +-------------------+
Fig. 11 -- Roaming and Distributed Services
图11——漫游和分布式服务
New entities that combine or add capabilities can be created to meet business needs. In figure 11, one such possibility, a SuperOrg entity is shown. The idea is that this entity would provide authentication and authorization for organizations that are providing services to end-users. It could be considered to be a wholesaler or broker. While not all authorization will require having a broker, authorization protocols should allow such entities to be created to meet legitimate requirements.
可以创建组合或添加功能的新实体以满足业务需求。在图11中，显示了一个SuperRG实体。其想法是，该实体将为向最终用户提供服务的组织提供身份验证和授权。它可以被认为是批发商或经纪人。虽然并非所有授权都需要有代理，但授权协议应允许创建此类实体以满足合法要求。
Having considered the basic players and how they interact, we will now consider different ways that authorization data may be stored in the network.
考虑到基本的参与者以及它们如何相互作用，我们现在将考虑授权数据可以存储在网络中的不同方式。
The Policy Framework (policy) Working Group is seeking to provide a framework to represent, manage, and share policies and policy information in a vendor-independent, interoperable, scalable manner. [5],[6],[7]. This section explores the relationship of policy and authorization and sets the stage for defining protocol requirements for supporting policy when included as part of multi-domain authorization. The work presented here builds on the policy framework, extending it to support policy across multiple domains.
政策框架（政策）工作组正在寻求提供一个框架，以独立于供应商、可互操作、可扩展的方式表示、管理和共享政策和政策信息。[5],[6],[7]. 本节探讨策略和授权之间的关系，并为定义支持策略的协议要求（当包含在多域授权中时）设置阶段。本文介绍的工作建立在策略框架的基础上，将其扩展到支持跨多个域的策略。
One view of an authorization is that it is the result of evaluating policies of each organization that has an interest in the authorization decision. In this document the assumption is that each administration may have policies which may be indexed by user, by service, or by other attributes of the request. The policies of each administration are defined independently of other administrations.
对授权的一种看法是，它是对每个对授权决策感兴趣的组织的策略进行评估的结果。在本文档中，假设每个管理可能都有策略，这些策略可以按用户、服务或请求的其他属性进行索引。每个行政部门的政策是独立于其他行政部门定义的。
Each independent policy must be 1) retrieved, 2) evaluated, and 3) enforced.
必须1）检索、2）评估和3）强制执行每个独立策略。
Policy definitions are maintained and stored in a policy repository [5] by (or on behalf of) the organization that requires them. The Policy Framework WG is working on a way to describe policy [7]. Other implementations describe policy as a set of ACL lists. Policy definitions must be retrieved in order to be evaluated and enforced. Policy Definitions can be indexed by requester, by service attribute, or by some other key. The organization requiring the policy is also responsible for determining which policy is to be applied to a specific authorization request.
策略定义由需要它们的组织（或其代表）维护并存储在策略存储库[5]中。政策框架工作组正在研究一种描述政策的方法[7]。其他实现将策略描述为一组ACL列表。必须检索策略定义才能进行评估和实施。策略定义可以由请求者、服务属性或某些其他键索引。需要该策略的组织还负责确定将哪个策略应用于特定的授权请求。
Policy retrieval is typically done by the administration that defines the policy or by an agent acting for that administration. Thus a policy defining the times of day that a particular User is allowed to connect to the network is maintained and retrieved by the User Organization. A policy defining a time that ports will be unusable because of maintenance is maintained and retrieved by the Service Provider.
策略检索通常由定义策略的管理部门或代理该管理部门执行。因此，定义允许特定用户连接到网络的时间的策略由用户组织维护和检索。定义端口因维护而不可用的时间的策略由服务提供商维护和检索。
Note that some implementation may choose to have the Service Provider retrieve a policy from the User Home Organization using a distributed directory access protocol. This may be appropriate in some cases, but is not a general solution. To understand why, suppose the remote administration and the home administration communicate via a broker which proxies their communications. In this case the remote and home
注意，一些实现可能会选择让服务提供者使用分布式目录访问协议从用户主组织检索策略。这在某些情况下可能是适当的，但不是一个普遍的解决办法。为了理解原因，假设远程管理和家庭管理通过代理其通信的代理进行通信。在这种情况下，远程和家庭
administrations have no prior relationship, and therefore the home administration directory is unlikely to be open for access by the remote administration and vice versa.
管理没有优先关系，因此主管理目录不太可能开放供远程管理访问，反之亦然。
Evaluation of policy requires access to information referenced by the policy. Often the information required is not available in the administration where the policy is retrieved. For example, checking that a user is allowed to login at the current time can readily be done by the User Home Organization because the User Home Organization has access to current time. But authorizing a user requiring a 2Mb/s path with less than 4 hops requires information available at a Service Provider and not directly available to the UHO, so the UHO must either 1) have a way to query a remote administration for the needed information or 2) forward the policy to the remote administration and have the remote administration do the actual evaluation or 3) attempt somehow to "shadow" the authoritative source of the information (e.g by having the Service Provider send updates to the UHO).
评估策略需要访问策略引用的信息。通常，在检索策略的管理中，所需的信息不可用。例如，检查用户是否允许在当前时间登录可以由用户主组织轻松完成，因为用户主组织可以访问当前时间。但授权需要2Mb/s路径且跳数少于4跳的用户需要服务提供商提供的信息，而UHO无法直接获得这些信息，因此，UHO必须1）能够查询远程管理部门所需的信息，或2）将策略转发给远程管理部门并让远程管理部门进行实际评估，或3）尝试以某种方式“隐藏”信息的权威来源（例如，让服务提供商向UHO发送更新）.
Applications might support either 1) or 2), and a general authorization protocol must allow both. Case 3) is not considered further as shadowing seems too "expensive" to be supported by an AAA protocol.
应用程序可能支持1）或2），并且通用授权协议必须同时允许这两种情况。案例3）没有进一步考虑，因为阴影似乎太“昂贵”，AAA协议不支持。
An example of case 1 is when a Service Provider forwards a request to a UHO which includes a query for the clearance code of the User. The Service Provider policy includes reference to the clearance code and the information in the reply is used as input to that policy.
情况1的一个示例是当服务提供商向UHO转发请求时，该请求包括对用户许可代码的查询。服务提供商策略包括对许可代码的引用，回复中的信息用作该策略的输入。
An example of case 2 is when the UHO approves an authorization conditional on the Service Provider confirming that there is currently a specific resource available for its use. The UHO includes the "policy" along with a conditional authorization to the Service Provider.
案例2的一个例子是，当UHO批准授权时，服务提供商必须确认当前存在可供其使用的特定资源。UHO包括“政策”以及对服务提供商的有条件授权。
Policy Enforcement is typically done by the Service Provider on the Service Equipment. The Service Equipment is equivalent to the Policy Target described in the Policy Framework [5]. Thus a NAS may enforce destination IP address limits via "filters" and a Router may enforce QoS restrictions on incoming packets. The protocol that sends the information between the Service Equipment and the Service Provider AAA Server may be specific to the Service Equipment, but it seems that the requirements are not different in kind from what is required between other AAA servers.
策略实施通常由服务提供商在服务设备上完成。服务设备相当于策略框架[5]中描述的策略目标。因此，NAS可以通过“过滤器”实施目的地IP地址限制，路由器可以对传入数据包实施QoS限制。在服务设备和服务提供商AAA服务器之间发送信息的协议可能特定于服务设备，但是看起来这些要求与其他AAA服务器之间的要求在性质上没有区别。
In particular, an AAA Server could send a "policy" to the Service Equipment stating what the equipment should do under various situations. The Service equipment should either set up to "enforce" the policy or reject the request.
特别是，AAA服务器可以向服务设备发送“策略”，说明设备在各种情况下应该做什么。服务设备应设置为“执行”策略或拒绝请求。
The AAA Server could also send a query to the Service Equipment for information it requires to evaluate a policy.
AAA服务器还可以向服务设备发送查询，以获取评估策略所需的信息。
A policy is retrieved by a Policy Retrieval Point (PRP) from a Policy Repository, evaluated at a Policy Decision Point (PDP) or Policy Consumer, and enforced at a Policy Enforcement Point (PEP) or Policy Target [5].
策略由策略检索点（PRP）从策略存储库中检索，在策略决策点（PDP）或策略使用者处评估，并在策略实施点（PEP）或策略目标处实施[5]。
Generally, any of the AAA Servers involved in an authorization transaction may retrieve a policy or evaluate a policy, and any of the Service Equipment may enforce a policy. Policy Repositories may reside on any of the AAA Servers or be located elsewhere in the network.
通常，授权事务中涉及的任何AAA服务器都可以检索策略或评估策略，并且任何服务设备都可以实施策略。策略存储库可以位于任何AAA服务器上，也可以位于网络中的其他位置。
Information against which policy conditions are evaluated (such as resource status, session state, or time of day) are accessible at Policy Information Points (PIPs) and might be accessed using Policy Information Blocks (PIBs). An interesting question in any authorization application that uses policy is where are the PDPs, PRPs, PIPs and PEPs?
在策略信息点（PIP）可以访问用于评估策略条件的信息（如资源状态、会话状态或时间），并且可以使用策略信息块（PIB）访问这些信息。在任何使用策略的授权应用程序中，一个有趣的问题是PDP、PRP、PIP和PEP在哪里？
Figure 12 shows which policy elements may be available at different points in the model. In distributed services, there may be multiple Service Providers involved in the authorization transaction, and each may act as the policy elements shown below.
图12显示了在模型的不同点可以使用哪些策略元素。在分布式服务中，授权事务中可能涉及多个服务提供者，每个服务提供者都可以充当如下所示的策略元素。
Note that the User (or requester) may also be a PRP (e.g. use policy description to specify what service is being requested), a PIP (have information needed by other entities to evaluate their policy), and a PDP (decide if it will accept a service with specific parameters).
请注意，用户（或请求者）也可能是PRP（例如，使用策略描述来指定所请求的服务）、PIP（具有其他实体评估其策略所需的信息）和PDP（决定是否接受具有特定参数的服务）。
+------+ +------------------------------+
| | | User Home Organization |
| | | +-------------------+ PRP |
| | | | AAA Server | PIP |
| | | | | PDP |
| | | +-------------------+ |
| | | |
| | +------------------------------+
| |
| |
| | +------------------------------+
| User | | Service Provider |
| | | +-------------------+ PRP |
| PRP | | | AAA Server | PIP |
| PIP | | | | PDP |
| PDP | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | PIP |
| | | | Equipment | PEP |
| | | +-------------------+ |
| | | |
+------+ +------------------------------+
+------+ +------------------------------+
| | | User Home Organization |
| | | +-------------------+ PRP |
| | | | AAA Server | PIP |
| | | | | PDP |
| | | +-------------------+ |
| | | |
| | +------------------------------+
| |
| |
| | +------------------------------+
| User | | Service Provider |
| | | +-------------------+ PRP |
| PRP | | | AAA Server | PIP |
| PIP | | | | PDP |
| PDP | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | PIP |
| | | | Equipment | PEP |
| | | +-------------------+ |
| | | |
+------+ +------------------------------+
PRP = Policy Retrieval Point PIP = Policy Information Point PDP = Policy Decision Point PEP = Policy Enforcement Point
PRP=策略检索点PIP=策略信息点PDP=策略决策点PEP=策略实施点
Fig. 12 -- Where Different Policy Elements May be Located
图12——不同的策略元素可能位于何处
An AAA protocol must be able to transport both policy definitions and the information needed to evaluate policies. It must also support queries for policy information.
AAA协议必须能够传输策略定义和评估策略所需的信息。它还必须支持对策略信息的查询。
This section outlines another mechanism that could be used for securely transporting the attributes on which an authorization decision is to be made. Work on X.509 Attribute Certificates is currently being undertaken in the Public Key Infrastructure (PKIX) Working Group [8]. This proposal is largely based on that work.
本节概述了另一种机制，该机制可用于安全地传输要做出授权决策的属性。公钥基础设施（PKIX）工作组目前正在进行X.509属性证书的工作[8]。这项建议主要基于这项工作。
When considering authorization using certificate-based mechanisms, one is often less interested in the identity of the entity than in some other attributes, (e.g. roles, account limits etc.), which should be used to make an authorization decision.
当考虑使用基于证书的机制进行授权时，人们通常对实体的身份不太感兴趣，而对一些其他属性（例如角色、帐户限制等）感兴趣，这些属性应用于做出授权决策。
In many such cases, it is better to separate this information from the identity for management, security, interoperability or other reasons. However, this authorization information may also need to be protected in a fashion similar to a public key certificate. The name used here for such a structure is an Attribute Certificate (AC) which is a digitally signed (certified) set of attributes.
在许多此类情况下，出于管理、安全性、互操作性或其他原因，最好将此信息与标识分开。然而，该授权信息也可能需要以类似于公钥证书的方式进行保护。此处用于此类结构的名称是属性证书（AC），它是一组经过数字签名（认证）的属性。
An AC is a structure that is similar to an X.509 public key certificate [9] with the main difference being that it contains no public key. The AC typically contains group membership, role, clearance and other access control information associated with the AC owner. A syntax for ACs is also defined in the X.509 standard.
AC是一种类似于X.509公钥证书[9]的结构，主要区别在于它不包含公钥。AC通常包含与AC所有者相关的组成员资格、角色、权限和其他访问控制信息。ACs的语法也在X.509标准中定义。
When making an access decision based on an AC, an access decision function (in a PEP, PDP or elsewhere) may need to ensure that the appropriate AC owner is the entity that has requested access. The linkage between the request and the AC can be achieved if the AC has a "pointer" to a Public Key Certificate (PKC) for the requester and that the PKC has been used to authenticate the request. Other forms of linkage can be defined which work with other authentication schemes.
当基于AC做出访问决策时，访问决策功能（在PEP、PDP或其他地方）可能需要确保适当的AC所有者是请求访问的实体。如果AC具有指向请求者公钥证书（PKC）的“指针”，并且PKC已用于验证请求，则可以实现请求与AC之间的链接。可以定义与其他身份验证方案一起使用的其他链接形式。
As there is often confusion about the difference between public key certificates (PKC's) and attribute certificates (ACs), an analogy may help. A PKC can be considered to be like a passport: it identifies the owner, it tends to be valid for a long period, it is difficult to forge, and it has a strong authentication process to establish the owner's identity. An AC is more like an entry visa in that it is typically issued by a different authority than the passport issuing authority, and it doesn't have as long a validity period as a passport. Acquiring an entry visa typically requires presenting a passport that authenticates that owner's identity. As a consequence, acquiring the entry visa becomes a simpler procedure. The entry visa will refer to the passport as a part of how that visa specifies the terms under which the passport owner is authorized to enter a country.
由于对公钥证书（PKC）和属性证书（ACs）之间的区别常常存在混淆，因此进行类比可能会有所帮助。PKC可以被看作是一本护照：它可以识别所有者，往往有效期很长，很难伪造，而且它有很强的身份验证过程来确定所有者的身份。AC更像是入境签证，因为它通常由不同于护照签发机构的机构签发，并且它的有效期没有护照那么长。获得入境签证通常需要出示能证明其所有者身份的护照。因此，获得入境签证变得更为简单。入境签证将提及护照，作为签证规定护照持有人获准入境条款的一部分。
In conjunction with authentication services, ACs provide a means to transport authorization information securely to applications. However, there are a number of possible communication paths that an AC may take.
结合身份验证服务，ACs提供了一种将授权信息安全地传输到应用程序的方法。然而，AC可以采用许多可能的通信路径。
In some environments, it is suitable for a client to "push" an AC to a server. This means that no new connections between the client and server domains are required. It also means that no search burden is imposed on servers, which improves performance.
在某些环境中，客户机可以将AC“推送”到服务器。这意味着客户端和服务器域之间不需要新的连接。这还意味着不会对服务器施加搜索负担，从而提高了性能。
In other cases, it is more suitable for a client simply to authenticate to the server and for the server to request the client's AC from an AC issuer or a repository. A major benefit of the this model is that it can be implemented without changes to the client and client/server protocol. It is also more suitable for some inter-domain cases where the client's rights should be assigned within the server's domain, rather than within the client's "home" domain.
在其他情况下，更适合于客户机向服务器进行身份验证，以及服务器从AC颁发者或存储库请求客户机的AC。此模型的一个主要优点是，它可以在不更改客户机和客户机/服务器协议的情况下实现。它还更适合于某些域间情况，在这种情况下，客户端的权限应该在服务器的域中分配，而不是在客户端的“主”域中分配。
There are a number of possible exchanges that can occur, and there are three entities involved: client, server, and AC issuer. In addition the use of a directory service as a repository for AC retrieval may be supported.
有许多可能发生的交换，涉及三个实体：客户端、服务器和AC颁发者。此外，还支持使用目录服务作为AC检索的存储库。
Figure 13 shows an abstract view of the exchanges that may involve ACs. Note that the lines in the diagram represent protocols which must be defined, not data flows. The PKIX working group will define the required acquisition protocols. One candidate for the lookup protocols is LDAP (once an LDAP schema exists which states where an AC is to be found).
图13显示了可能涉及ACs的交换的抽象视图。请注意，图中的行表示必须定义的协议，而不是数据流。PKIX工作组将定义所需的采集协议。查找协议的一个候选者是LDAP（一旦存在LDAP模式，该模式说明将在何处找到AC）。
+--------------+ +---------------+
| AAA Server/ | | |
| AC Issuer +----+ | Directory |
| | | | |
+--+-----------+ | Server +-------+-------+
| | Acquisition |
|Client | |Server
|Acquisition +----------------------+ |Lookup
| | |
+--+-----------+ +--+----+-------+
| | AC in application | Service |
| User +------------------------+ Equipment/ |
| | protocol | AAA Server |
+--+-----------+ +---------------+
|
| Client Lookup
+--+-----------+
| |
| Directory |
| |
+--------------+
+--------------+ +---------------+
| AAA Server/ | | |
| AC Issuer +----+ | Directory |
| | | | |
+--+-----------+ | Server +-------+-------+
| | Acquisition |
|Client | |Server
|Acquisition +----------------------+ |Lookup
| | |
+--+-----------+ +--+----+-------+
| | AC in application | Service |
| User +------------------------+ Equipment/ |
| | protocol | AAA Server |
+--+-----------+ +---------------+
|
| Client Lookup
+--+-----------+
| |
| Directory |
| |
+--------------+
Fig. 13 -- AC Exchanges
图13——交流交换机
Figure 14 shows the data flows which may occur in one particular case, that termed "push" above (section 2.1.3).
图14显示了在一种特殊情况下可能出现的数据流，即上文所述的“推送”（第2.1.3节）。
+--------------+
| AAA Server/ |
| AC Issuer |
| |
+--+-----------+
|
|Client
|Acquisition (1)
|
+--+-----------+ +---------------+
| | AC in application | Service |
| User +------------------------+ Equipment/ |
| | protocol (2) | AAA Server |
+--------------+ +---------------+
+--------------+
| AAA Server/ |
| AC Issuer |
| |
+--+-----------+
|
|Client
|Acquisition (1)
|
+--+-----------+ +---------------+
| | AC in application | Service |
| User +------------------------+ Equipment/ |
| | protocol (2) | AAA Server |
+--------------+ +---------------+
Fig. 14 -- One example of an AC exchange
图14——交流交换机的一个示例
In the diagram, the user first contacts the AC Issuer and then incorporates the AC into the application protocol. The Service Equipment must then validate the AC and use it as the basis for the access decision (this functionality may be distributed between a PEP and PDP).
在图中，用户首先联系AC颁发者，然后将AC合并到应用程序协议中。然后，服务设备必须验证AC，并将其用作访问决策的基础（此功能可在PEP和PDP之间分配）。
Authorization requests may be chained through a set of servers, as described in previous sections. Each of the servers may have a contractual relationship with servers on either side of it in the chain. In many of the applications being considered, the authorization results in establishing of an ongoing service which we call a session. Each of the servers involved in the authorization may also want to keep track of the state of the session, and be able to effect changes to the session if required. To make it simple to discuss this capability, we assume that each AAA Server MAY have a Resource Manager component. Resource Managers tracking the same session need to be able to initiate changes to the session, and to inform other Resource Managers when changes occur. Communication between Resource Managers creates requirements for an authorization protocol.
授权请求可以通过一组服务器链接，如前几节所述。每台服务器都可能与链中任何一方的服务器存在合同关系。在许多正在考虑的应用程序中，授权会导致建立一个正在进行的服务，我们称之为会话。参与授权的每个服务器可能还希望跟踪会话的状态，并能够在需要时对会话进行更改。为了简化对该功能的讨论，我们假设每个AAA服务器可能都有一个资源管理器组件。跟踪同一会话的资源管理器需要能够启动对会话的更改，并在发生更改时通知其他资源管理器。资源管理器之间的通信创建了授权协议的需求。
An example of the use of resource management might be a user which sets up a QoS path through two ISPs, and while this path is active, one of the ISPs gets a request for more bandwidth from a higher priority user. The ISP may need to take some bandwidth from a the lower priority user's previously allocated session and give it to the
使用资源管理的一个示例可能是用户通过两个ISP设置QoS路径，并且当该路径处于活动状态时，其中一个ISP从优先级较高的用户处获得更多带宽的请求。ISP可能需要从低优先级用户先前分配的会话中获取一些带宽，并将其提供给
new request. To do this, each of the administrations in the authorization path must be informed and agree to the change (this could be considered to be "authorizing the new value").
新的请求。为此，必须通知授权路径中的每个管理部门并同意变更（这可以被视为“授权新值”）。
When an AAA Server grants authorization of some resource to an AAA requester (either a User or another AAA Server), the server may need to maintain session state information. This is used to make decisions about new sessions based on the state of current sessions, and to allow monitoring of sessions by all interested AAA Servers.
当AAA服务器向AAA请求者（用户或其他AAA服务器）授予某些资源的授权时，服务器可能需要维护会话状态信息。这用于根据当前会话的状态决定新会话，并允许所有感兴趣的AAA服务器监视会话。
Each session is identified by a session identifier, which must be unique within each AAA Server. Communication between AAA Servers must include the session identifier. It is desirable that the session identifier is the same across all AAA servers, otherwise each server will have to map identifiers from other servers to its own identifiers. A single session identifier significantly simplifies auditing and session control functions.
每个会话由会话标识符标识，该标识符在每个AAA服务器中必须是唯一的。AAA服务器之间的通信必须包括会话标识符。希望所有AAA服务器的会话标识符都相同，否则每个服务器都必须将其他服务器的标识符映射到自己的标识符。单个会话标识符大大简化了审核和会话控制功能。
Maintaining session state across AAA administrative boundaries increases the complexity of the problem, especially if each AAA Server in the trust chain must keep state as well. This can be viewed as an interdomain database replication problem. The protocol must include tools to help manage replicated state. Some of the problems to be addressed are:
跨AAA管理边界维护会话状态会增加问题的复杂性，尤其是当信任链中的每个AAA服务器也必须保持状态时。这可以看作是域间数据库复制问题。协议必须包括帮助管理复制状态的工具。需要解决的一些问题包括：
a) Service Equipment must be able to notify its Resource Manager when a session terminates or changes state in some other way. The Resource Manager must inform other Resource Managers which keep state for this session.
a) 当会话终止或以其他方式更改状态时，服务设备必须能够通知其资源管理器。资源管理器必须通知保持此会话状态的其他资源管理器。
b) The Resource Manager will need to set a time limit for each session which must be refreshed by having the Resource Manager query for authoritative status or by having the authoritative source send periodic keep alive messages that are forwarded to all Resource Managers in the authorization chain. Determining the appropriate session lifetime may be application specific and depends on the acceptable level of risk. If the service being offered is billed based on time, the session lifetime may need to be relatively small; if the service is billed on usage, the lifetime may be relatively large.
b) 资源管理器需要为每个会话设置时间限制，必须通过让资源管理器查询权威状态或让权威源定期发送保持活动的消息来刷新会话，这些消息将转发给授权链中的所有资源管理器。确定适当的会话生存期可能是特定于应用程序的，并且取决于可接受的风险级别。如果所提供的服务是基于时间计费的，则会话生存期可能需要相对较小；如果服务是按使用情况计费的，则生命周期可能相对较大。
c) Any Resource Manager in the chain must have the ability to terminate a session. This requires the Resource Manager to have knowledge of at least the adjacent AAA Servers in the authorization chain.
c) 链中的任何资源管理器都必须能够终止会话。这要求资源管理器至少了解授权链中相邻的AAA服务器。
An example of how resource management can be used is in the PPP dialin application. A home ISP may wish to restrict the number of concurrent sessions that a user can have at any given time. This is particularly important when service providers give all-you-can-eat Internet access. The possibility for fraud is quite large, since a user could provide his or her username/password to many people, causing a loss of revenue. Resource management would allow the home ISP AAA server to identify when a user is active and to reject any authorization request for the user until termination indication is received from the NAS or until the session expires.
如何使用资源管理的一个示例是PPP拨号应用程序。家庭ISP可能希望限制用户在任何给定时间可以拥有的并发会话的数量。这一点在服务提供商为您提供互联网接入服务时尤为重要。欺诈的可能性相当大，因为用户可以向许多人提供其用户名/密码，从而造成收入损失。资源管理将允许家庭ISP AAA服务器识别用户何时处于活动状态，并拒绝用户的任何授权请求，直到从NAS收到终止指示或会话过期为止。
This section describes the functions of the Resource Manager in more detail.
本节更详细地描述了资源管理器的功能。
The Resource Manager is the component which tracks the state of sessions associated with an AAA Server or Service Equipment. It also may allocate resources to a session (e.g. IP addresses) and may track use of resources allocated by peer resource managers to a session (e.g. bandwidth in a foreign administrative domain). The resource manager also provides interfaces to allow the User to acquire or release authorized sessions.
资源管理器是跟踪与AAA服务器或服务设备关联的会话状态的组件。它还可以将资源分配给会话（例如，IP地址），并且可以跟踪对等资源管理器分配给会话的资源的使用情况（例如，外部管理域中的带宽）。资源管理器还提供允许用户获取或释放授权会话的接口。
The Resource Manager maintains all session specific AAA state information required by the AAA Server. That state information may include pointers to peer Resource Managers in other administrative domains that possess additional AAA state information that refers to the same session. The Resource Manager is the anchor point in the AAA Server from which a session can be controlled, monitored, and coordinated even if that session is consuming network resources or services across multiple Service Provider administrative domains.
资源管理器维护AAA服务器所需的所有特定于会话的AAA状态信息。该状态信息可以包括指向其他管理域中的对等资源管理器的指针，这些管理域具有引用同一会话的附加AAA状态信息。资源管理器是AAA服务器中的锚定点，从中可以控制、监视和协调会话，即使该会话正在跨多个服务提供商管理域使用网络资源或服务。
The Resource Manager has several important functions:
资源管理器有几个重要功能：
a) It allows a Service Provider operations staff to inspect the status of any of the allocated resources and services including resources that span foreign Service Provider administrative boundaries. The peer Resource Managers will cooperatively share only the state information subset that is required to assist in diagnosing cross-domain trouble tickets. The network operator may also modify or altogether cancel one of the User's active authorizations.
a) 它允许服务提供商运营人员检查任何已分配资源和服务的状态，包括跨越外部服务提供商管理边界的资源。对等资源管理器将仅协作共享帮助诊断跨域故障单所需的状态信息子集。网络运营商还可以修改或完全取消用户的一个活动授权。
b) It is the process contacted by other Resource Managers to inform the AAA Server that a specific session has been cancelled. This information is relayed to the other peer Resource Managers that also know about that session and hence must cancel it.
b) 它是其他资源管理器联系的流程，用于通知AAA服务器特定会话已取消。此信息将转发给其他对等资源管理器，这些对等资源管理器也知道该会话，因此必须取消该会话。
c) The Resource Manager conceals the identity and location of its private internal AAA components from other administrative domains and from the User, while at the same time facilitating cooperation between those domains.
c) 资源管理器向其他管理域和用户隐藏其私有内部AAA组件的身份和位置，同时促进这些域之间的合作。
d) The Resource Manager cooperates with "policy servers" or Policy Decision Points (PDPs). The Resource Manager maintains internal state information, possibly complex cross-administrative domain information, supported by dialogues with its peer Resource Managers. A policy server can use the state information when evaluating a particular policy.
d) 资源管理器与“策略服务器”或策略决策点（PDP）协作。资源管理器维护内部状态信息，可能是复杂的跨管理域信息，由与其对等资源管理器的对话支持。策略服务器在评估特定策略时可以使用状态信息。
e) The separation of the Resource Manager and the policy server into two distinct architectural components allows a single session to span multiple administrative domains, where each administrative domain has one or more policy server cooperating with its Resource Manager.
e) 将资源管理器和策略服务器分离为两个不同的体系结构组件允许单个会话跨越多个管理域，其中每个管理域都有一个或多个策略服务器与其资源管理器协作。
AAA resource managers will normally use the same trust relationships needed for authorization sequences. It is possible for independent relationships to be established, but that is discouraged.
AAA资源管理器通常会使用授权序列所需的相同信任关系。建立独立的关系是可能的，但不鼓励这样做。
An AAA Server is responsible for securely forwarding AAA messages to the correct destination system or process in the AAA infrastructure. Two well known examples are forwarding AAA messages for a roaming AAA service, and forwarding AAA messages for a distributed AAA service. The same principle can also be applied to intra-domain communications. The message forwarding is done in one of two modes.
AAA服务器负责将AAA消息安全地转发到AAA基础结构中的正确目标系统或进程。两个众所周知的示例是为漫游AAA服务转发AAA消息，以及为分布式AAA服务转发AAA消息。同样的原理也可以应用于域内通信。消息转发以两种模式之一完成。
The first mode is when an AAA server needs to forward a message to a peer AAA server that has a known "logical destination address" that must be resolved by an application-specific procedure into its actual network address. Typically the forwarding procedure indexes into a database by an application-specific identifier to discover the peer's network address. For example, in the roaming dialin application, the application-specific identifier may be an NAI. A bandwidth brokerage application would use other search indices unique to its problem domain to select the addressed peer AAA server. After the address resolution procedure has completed successfully, then the AAA server transmits the message to its peer over the connection associated with that destination network address.
第一种模式是AAA服务器需要将消息转发给对等AAA服务器，该服务器具有已知的“逻辑目标地址”，必须通过特定于应用程序的过程将该地址解析为其实际网络地址。通常，转发过程通过特定于应用程序的标识符索引到数据库中，以发现对等方的网络地址。例如，在漫游拨号应用中，应用特定标识符可以是NAI。带宽代理应用程序将使用其问题域特有的其他搜索索引来选择寻址的对等AAA服务器。地址解析过程成功完成后，AAA服务器通过与该目标网络地址相关联的连接将消息传输给其对等方。
The second mode is when the AAA server already has an established session representing an authorization. The session's state contains the addressing and context used to direct the message to its destination peer AAA server, PDP, PEP, or User. The message is sent
第二种模式是AAA服务器已经建立了表示授权的会话。会话的状态包含用于将消息定向到其目标对等AAA服务器、PDP、PEP或用户的寻址和上下文。消息已发送
over the AAA server's connection to that destination peer, multiplexed with other session's messages. The message must be qualified by a session identifier that is understood by both end points. The AAA message's destination may be either intra-administrative domain, or inter-administrative domain. In the former case, the destination process may reside on the same system as the AAA server.
通过AAA服务器与目标对等方的连接，与其他会话的消息进行多路传输。消息必须由两个端点都能理解的会话标识符限定。AAA消息的目的地可以是管理域内或管理域间。在前一种情况下，目标进程可以驻留在与AAA服务器相同的系统上。
In addition to the above message forwarding processing, the underlying message delivery service must meet the following requirements:
除上述邮件转发处理外，基础邮件传递服务还必须满足以下要求：
- Unicast capability -- An end system can send a message to any other end system with minimal latency of session setup/disconnect overhead messages, and no end system overhead of keeping state information about every potential peer.
- 单播功能——终端系统可以向任何其他终端系统发送消息，会话设置/断开连接开销消息的延迟最小，并且没有保留每个潜在对等方状态信息的终端系统开销。
- Data integrity and error detection -- This data transport protocol assumes an underlying datagram network layer service that includes packet discard on error detection, and data integrity protection against third party modifications.
- 数据完整性和错误检测——此数据传输协议假定基础数据报网络层服务，包括错误检测时的数据包丢弃，以及针对第三方修改的数据完整性保护。
- Reliable data transport assurance -- When an end system successfully receives a message marked receipt requested, it must acknowledge that message to the sending system by either piggybacking the acknowledgement on an application-specific reply message, or else as a standalone acknowledgement message. The sending system maintains a retry timer; when the timer expires, the sending system retransmits a copy of its original message. It gives up after a configurable number of unsuccessful retries.
- 可靠的数据传输保证——当终端系统成功接收到标记为Receive requested的消息时，它必须通过在特定于应用程序的回复消息上附带确认信息或作为独立确认消息向发送系统确认该消息。发送系统维护重试定时器；当计时器过期时，发送系统将重新传输其原始消息的副本。在可配置的失败重试次数后，它将放弃。
- Sequenced data delivery -- If multiple messages are sent between a pair of end systems, those messages are delivered to the addressed application in the same order as they were transmitted. Duplicates are silently suppressed.
- 顺序数据传递——如果在一对终端系统之间发送多条消息，则这些消息将以与传输相同的顺序传递到寻址应用程序。重复项将被静默抑制。
- Responsive to network congestion feedback -- When the network enters into congestion, the end systems must detect that condition, and they must back off their transmission rate until the congestion subsides. The back off and recovery algorithms must avoid oscillations.
- 响应网络拥塞反馈——当网络进入拥塞时，终端系统必须检测到这种情况，并且必须降低传输速率，直到拥塞消退。退避和恢复算法必须避免振荡。
When AAA servers communicate through intermediate AAA servers, such as brokers, it may be necessary that a part of the payload be secure between the originator and the target AAA server. The security requirement may consist of one or more of the following: end-to-end
当AAA服务器通过中间AAA服务器（例如代理）进行通信时，可能需要在发起方和目标AAA服务器之间保护有效负载的一部分。安全要求可能包括以下一项或多项：端到端
message integrity, confidentiality, replay protection, and nonrepudiation. Furthermore, it is a requirement that intermediate AAA servers be able to append information such as local policy to a message before forwarding the message to its intended destination. It may also be required that an intermediate AAA Server sign such appended information.
消息完整性、机密性、重播保护和不可否认性。此外，要求中间AAA服务器能够在将消息转发到其预期目的地之前将诸如本地策略之类的信息附加到消息。还可能要求中间AAA服务器签署此类附加信息。
This requirement has been clearly documented in [10], which describes many current weaknesses of the RADIUS protocol [11] in roaming networks since RADIUS does not provide such functionality. One well-known attack is the ability for the intermediate nodes to modify critical accounting information, such as a session time.
[10]中明确记录了这一要求，其中描述了漫游网络中RADIUS协议[11]的许多当前弱点，因为RADIUS不提供此类功能。一种众所周知的攻击是中间节点修改关键记帐信息（如会话时间）的能力。
Most popular security protocols (e.g. IPSec, SSL, etc.) do not provide the ability to secure a portion of the payload. Therefore, it may be necessary for the AAA protocol to implement its own security extensions to provide end-to-end security.
大多数流行的安全协议（如IPSec、SSL等）不提供保护部分有效负载的能力。因此，AAA协议可能需要实现其自身的安全扩展以提供端到端安全性。
The techniques described above allow for great flexibility in distributing the components required for authentication and authorization. However, working groups such as Roamops and MobileIP have identified requirements to minimize Internet traversals in order to reduce latency. To support these requirements, data fields necessary for both authentication and authorization SHOULD be able to be carried in a single message set. This is especially important when there are intermediate servers (such as Brokers) in the AAA chain.
上述技术允许在分发身份验证和授权所需的组件时具有极大的灵活性。然而，Roamops和MobileIP等工作组已经确定了最小化互联网访问以减少延迟的要求。为了支持这些要求，身份验证和授权所需的数据字段应该能够在单个消息集中携带。当AAA链中存在中间服务器（如代理）时，这一点尤为重要。
Furthermore, it should be possible for the Brokers to allow end-to-end (direct) authentication and authorization. This can be done as follows. The User Home Organization generates a ticket which is signed using the UHO's private key. The ticket is carried in the accounting messages. The accounting messages must flow through the Broker since the Broker is acting as the settlement agent and requires this information. There are Brokers that will require to be in the authentication and authorization path as well since they will use this information to detect fraudulent activity, so the above should be optional.
此外，代理应该可以允许端到端（直接）身份验证和授权。这可以按如下方式进行。用户主组织生成使用UHO私钥签名的票据。票据在会计信息中携带。会计消息必须流经代理，因为代理充当结算代理，并且需要此信息。有些代理也需要位于身份验证和授权路径中，因为它们将使用此信息来检测欺诈活动，因此上述内容应该是可选的。
In order for end-to-end authentication and authorization to occur, it may be necessary for the Broker to act as a certificate authority. All members of the roaming consortium would be able to trust each other (to an extent) using the certificates. A Service Provider's AAA server that sends a request to the Broker should be able to receive a redirect message which would allow the two peers (Service Provider and UHO) to interact directly. The redirect message from
为了进行端到端身份验证和授权，代理可能需要充当证书颁发机构。漫游联盟的所有成员将能够使用证书（在一定程度上）相互信任。向代理发送请求的服务提供商的AAA服务器应该能够接收重定向消息，这将允许两个对等方（服务提供商和UHO）直接交互。来自的重定向消息
the Broker should include the UHO's certificate, which eliminates the Service Provider from accessing the certificate archive. The request from the Service Provider could include its own certificate, and a token from the Broker's redirect message that is timestamped and guarantees that the Service Provider is in good standing with the Broker. This eliminates the home domain from accessing the Certificate Revocation List (CRL).
代理应包括UHO的证书，这将消除服务提供商访问证书存档的权限。来自服务提供者的请求可以包括它自己的证书，以及来自代理的重定向消息的令牌，该令牌带有时间戳，并保证服务提供者与代理的关系良好。这将使主域无法访问证书吊销列表（CRL）。
The above has introduced the basic players in an authorization transaction as User, User Home Organization, Service Provider's AAA Server, and Service Equipment. It has discussed relationships between entities based on agreements or contracts, and on "trust". Examples of authorization sequences have been given.
上面介绍了授权事务中的基本参与者，如用户、用户主组织、服务提供商的AAA服务器和服务设备。它讨论了基于协议或合同以及基于“信任”的实体之间的关系。已经给出了授权序列的示例。
Concepts of roaming and distributed services have been briefly described. Combination of roaming and distributed services was also considered and the concept of a "wholesaler" or Broker was introduced. We have considered the use of policies and attribute certificates to store and transmit authorization data. We discussed the problem of managing the resources to which access has been authorized including the problem of tracking state information for session-oriented services, and we defined the Resource Manager component of a AAA Server. We considered the problem of forwarding AAA messages among servers in possibly different administrative domains. We considered the need for end-to-end security of portions of the payload of authorization messages that pass through intermediate AAA Servers. Finally we stressed the need for support of a streamlined authorization process that minimizes delay for latency-sensitive applications.
本文简要介绍了漫游和分布式服务的概念。还考虑了漫游和分布式服务的结合，并引入了“批发商”或经纪人的概念。我们考虑了使用策略和属性证书来存储和传输授权数据。我们讨论了管理已授权访问的资源的问题，包括跟踪面向会话服务的状态信息的问题，并定义了AAA服务器的资源管理器组件。我们考虑了在可能不同的管理域中的服务器之间转发AAA消息的问题。我们考虑了对通过中间AAA服务器的授权消息有效负载部分的端到端安全性的需要。最后，我们强调需要支持简化的授权过程，以最大限度地减少延迟敏感应用程序的延迟。
The intent is that this will provide support for discussing and understanding requirements of specific applications that need authorization services.
其目的是为讨论和理解需要授权服务的特定应用程序的需求提供支持。
Authorization is itself a security mechanism. As such, it is important that authorization protocols cannot easily be abused to circumvent the protection they are intended to ensure. It is the responsibility of protocol designers to design their protocols to be resilient against well-known types of attacks. The following are some considerations that may guide protocol designers in the development of authorization protocols.
授权本身就是一种安全机制。因此，重要的是，授权协议不能轻易被滥用，以规避其旨在确保的保护。协议设计者的责任是设计他们的协议，使其能够抵御已知类型的攻击。以下是一些可以指导协议设计人员开发授权协议的注意事项。
Authorization protocols must not be susceptible to replay attacks. If authentication data is carried with the authorization data, for example, the authentication protocol used must either be impervious to replay or else the confidentiality of the authentication data must be protected.
授权协议不得受到重播攻击的影响。例如，如果身份验证数据与授权数据一起携带，则所使用的身份验证协议必须不受重播的影响，否则必须保护身份验证数据的机密性。
If proxying is required, the authorization protocol must not be susceptible to man-in-the-middle attacks.
如果需要代理，则授权协议不得容易受到中间人攻击。
If the push model is used, the confidentiality of the authorization data must be ensured so that it may not be hijacked by third parties and used to obtain a service fraudulently.
如果使用推送模型，则必须确保授权数据的机密性，以使其不会被第三方劫持并用于欺诈性地获取服务。
If the agent model is used, the binding between the authorization and the service itself must be protected to prevent service authorized to one party from being fraudulently received by another.
如果使用代理模型，则必须保护授权和服务本身之间的绑定，以防止授权给一方的服务被另一方欺诈地接收。
In addition to guarding against circumvention, authorization protocols designed according to this framework will have some intrinsic security requirements. These are included among the requirements in [2] and summarized briefly below.
除了防止规避之外，根据该框架设计的授权协议还具有一些固有的安全要求。这些包括在[2]中的要求中，并简要总结如下。
Among the intrinsic security needs is the fact that authorization protocols may carry sensitive information. It is necessary to protect such information from disclosure to unauthorized parties including (as discussed in section 8) even certain parties involved in the authorization decision.
固有的安全需求之一是授权协议可能携带敏感信息。有必要保护此类信息不被披露给未经授权的方，包括（如第8节所述）甚至参与授权决策的某些方。
We have discussed the use of multi-party trust chains involving relaying of authorization data through brokers or other parties. In such cases, the integrity of the chain must be maintained. It may be necessary to protect the data exchanged between parties using such mechanisms as encryption and digital signatures.
我们已经讨论了多方信任链的使用，涉及通过代理或其他方中继授权数据。在这种情况下，必须保持链条的完整性。可能需要使用加密和数字签名等机制来保护各方之间交换的数据。
Finally, because authorization will be necessary to gain access to many Internet services, a denial of service attack against an authorization server can be just as effective as a denial of service attack against the service equipment itself in preventing access to Internet services.
最后，由于访问许多Internet服务需要授权，因此针对授权服务器的拒绝服务攻击在阻止访问Internet服务方面与针对服务设备本身的拒绝服务攻击一样有效。
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. [12]
安全关联——一对节点之间的安全上下文集合，可应用于它们之间交换的协议消息。每个上下文都表示身份验证算法和模式、秘密（共享密钥或适当的公钥/私钥对）以及使用的重播保护类型。[12]
Service Equipment -- the equipment which provides a service.
服务设备——提供服务的设备。
Service Provider -- an organization which provides a service.
服务提供者——提供服务的组织。
Static Trust Relationship -- a pre-established secure relationship between two entities created by a trusted party. This relationship facilitates the exchange of AAA messages with a certain level of security and traceability. Example: A network operator (trusted party) who has access to the wiring closet
静态信任关系——由受信任方创建的两个实体之间预先建立的安全关系。这种关系有助于AAA消息的交换，具有一定的安全性和可跟踪性。示例：有权访问接线柜的网络运营商（受信任方）
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.
在用户的墙上插座和特定网络端口之间创建连接。用户在一定程度上被信任连接到这个特定的网络端口。
User -- the entity seeking authorization to use a resource or a service.
用户——寻求使用资源或服务的授权的实体。
User Home Organization (UHO) -- An organization with whom the User has a contractual relationship which can authenticate the User and may be able to authorize access to resources or services.
用户总部组织（UHO）——用户与之有合同关系的组织，可以对用户进行身份验证，并且可以授权访问资源或服务。
References
工具书类
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[2] Farrell, S., Vollbrecht, J., Calhoun, P., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Requirements", RFC 2906, August 2000.
[2] Farrell，S.，Vollbrecht，J.，Calhoun，P.，Gommans，L.，Gross，G.，de Bruijn，B.，de Laat，C.，Holdrege，M.和D.Spence，“AAA授权要求”，RFC 2906，2000年8月。
[3] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Application Examples", RFC 2905, August 2000.
[3] Vollbrecht，J.，Calhoun，P.，Farrell，S.，Gommans，L.，Gross，G.，de Bruijn，B.，de Laat，C.，Holdrege，M.和D.Spence，“AAA授权应用示例”，RFC 2905，2000年8月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Stevens, M., "Policy Framework", Work in Progress.
[5] Stevens，M.，“政策框架”，正在进行中。
[6] Strassner, John, Ed Ellesson, and Bob Moore, "Policy Core Information Model -- Version 1 Specification", Work in Progress.
[6] Strassner、John、Ed Ellsson和Bob Moore，“策略核心信息模型——版本1规范”，正在进行中。
[7] Strassner, John, et al, "Policy Framework LDAP Core Schema", Work in Progress.
[7] Strassner，John等，“策略框架LDAP核心模式”，正在进行中。
[8] Farrell, Stephen and Russell Housley, "An Internet Attribute Certificate Profile for Authorization", Work in Progress.
[8] Farrell、Stephen和Russell Housley，“用于授权的Internet属性证书配置文件”，正在进行中。
[9] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure -- Certificate and CRL Profile", RFC 2459, January 1999.
[9] Housley，R.，Ford，W.，Polk，W.和D.Solo，“Internet X.509公钥基础设施——证书和CRL配置文件”，RFC 2459，1999年1月。
[10] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[10] Aboba，B.和J.Vollbrecht，“漫游中的代理链接和策略实施”，RFC 2607，1999年6月。
[11] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[11] Rigney，C.，Rubens，A.，Simpson，W.和S.Willens，“远程认证拨入用户服务（RADIUS）”，RFC 21381997年4月。
[12] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[12] Perkins，C.，“IP移动支持”，RFC 2002，1996年10月。
[13] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[13] Yavatkar，R.，Pendarakis，D.和R.Guerin，“基于政策的准入控制框架”，RFC 2753，2000年1月。
Authors' Addresses
作者地址
John R. Vollbrecht Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA
John R.Vollbrecht Interlink Networks，Inc.美国密歇根州安阿伯市科技大道775号200室，邮编：48108
Phone: +1 734 821 1205
Fax: +1 734 821 1235
Mail: jrv@interlinknetworks.com
Phone: +1 734 821 1205
Fax: +1 734 821 1235
Mail: jrv@interlinknetworks.com
Pat R. Calhoun Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA
Pat R.Calhoun网络和安全研究中心，太阳实验室太阳微系统公司，美国加利福尼亚州门罗公园网络圈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编辑功能的资金目前由互联网协会提供。