Network Working Group C. de Laat
Request for Comments: 2903 Utrecht University
Category: Experimental G. Gross
Lucent Technologies
L. Gommans
Enterasys Networks EMEA
J. Vollbrecht
D. Spence
Interlink Networks, Inc.
August 2000
Network Working Group C. de Laat
Request for Comments: 2903 Utrecht University
Category: Experimental G. Gross
Lucent Technologies
L. Gommans
Enterasys Networks EMEA
J. Vollbrecht
D. Spence
Interlink Networks, Inc.
August 2000
Generic AAA Architecture
通用AAA体系结构
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This memo proposes an Authentication, Authorization, Accounting (AAA) architecture that would incorporate a generic AAA server along with an application interface to a set of Application Specific Modules that could perform application specific AAA functions. A separation of AAA functions required in a multi-domain environment is then proposed using a layered protocol abstraction. The long term goal is to create a generic framework which allows complex authorizations to be realized through a network of interconnected AAA servers.
本备忘录提出了一种认证、授权、计费（AAA）体系结构，该体系结构将通用AAA服务器和应用程序接口结合到一组可执行应用程序特定AAA功能的应用程序特定模块中。然后，使用分层协议抽象提出了多域环境中所需AAA功能的分离。长期目标是创建一个通用框架，允许通过互连AAA服务器网络实现复杂授权。
Table of Contents
目录
1. Introduction ................................................ 2
2. Generic AAA Architecture .................................... 4
2.1. Architectural Components of a Generic AAA Server ....... 4
2.1.1. Authorization Rule Evaluation ................... 4
2.1.2. Application Specific Module (ASM) ............... 5
2.1.3. Authorization Event Log ......................... 6
2.1.4. Policy Repository ............................... 6
2.1.5. Request Forwarding .............................. 6
2.2. Generic AAA Server Model ............................... 6
2.2.1. Generic AAA Server Interactions ................. 7
2.2.2. Compatibility with Legacy Protocols ............. 7
2.2.3. Interaction between the ASM and the Service ..... 9
2.2.4. Multi-domain Architecture ....................... 10
2.3. Model Observations ..................................... 10
2.4. Suggestions for Future Work ............................ 11
3. Layered AAA Protocol Model .................................. 12
3.1. Elements of a Layered Architecture ..................... 14
3.1.1. Service Layer Abstract Interface Primitives ..... 14
3.1.2. Service Layer Peer End Point Name Space ......... 14
3.1.3. Peer Registration, Discovery, and Location
Resolution ............................................. 14
3.1.4. Trust Relationships Between Peer End Points ..... 14
3.1.5. Service Layer Finite State Machine .............. 15
3.1.6. Protocol Data Unit Types ........................ 15
3.2. AAA Application Specific Service Layer ................. 15
3.3. Presentation Service Layer ............................. 16
3.4. AAA Transaction/Session Management Service Layer ....... 17
3.5. AAA-TSM Service Layer Program Interface Primitives ..... 20
3.6. AAA-TSM Layer End Point Name Space ..................... 21
3.7. Protocol Stack Examples ................................ 22
4. Security Considerations ..................................... 22
Glossary ....................................................... 23
References ..................................................... 24
Authors' Addresses ............................................. 24
Full Copyright Statement ....................................... 26
1. Introduction ................................................ 2
2. Generic AAA Architecture .................................... 4
2.1. Architectural Components of a Generic AAA Server ....... 4
2.1.1. Authorization Rule Evaluation ................... 4
2.1.2. Application Specific Module (ASM) ............... 5
2.1.3. Authorization Event Log ......................... 6
2.1.4. Policy Repository ............................... 6
2.1.5. Request Forwarding .............................. 6
2.2. Generic AAA Server Model ............................... 6
2.2.1. Generic AAA Server Interactions ................. 7
2.2.2. Compatibility with Legacy Protocols ............. 7
2.2.3. Interaction between the ASM and the Service ..... 9
2.2.4. Multi-domain Architecture ....................... 10
2.3. Model Observations ..................................... 10
2.4. Suggestions for Future Work ............................ 11
3. Layered AAA Protocol Model .................................. 12
3.1. Elements of a Layered Architecture ..................... 14
3.1.1. Service Layer Abstract Interface Primitives ..... 14
3.1.2. Service Layer Peer End Point Name Space ......... 14
3.1.3. Peer Registration, Discovery, and Location
Resolution ............................................. 14
3.1.4. Trust Relationships Between Peer End Points ..... 14
3.1.5. Service Layer Finite State Machine .............. 15
3.1.6. Protocol Data Unit Types ........................ 15
3.2. AAA Application Specific Service Layer ................. 15
3.3. Presentation Service Layer ............................. 16
3.4. AAA Transaction/Session Management Service Layer ....... 17
3.5. AAA-TSM Service Layer Program Interface Primitives ..... 20
3.6. AAA-TSM Layer End Point Name Space ..................... 21
3.7. Protocol Stack Examples ................................ 22
4. Security Considerations ..................................... 22
Glossary ....................................................... 23
References ..................................................... 24
Authors' Addresses ............................................. 24
Full Copyright Statement ....................................... 26
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
本备忘录的工作由一个小组完成，该小组最初是IETF AAA工作组的授权小组。当AAA工作组章程更改为侧重于MobileIP和NAS需求时，AAAarch研究组在IRTF内获得了特许，以继续并扩展授权小组开始的体系结构工作。该备忘录是该小组创建的四份备忘录之一。本备忘录是AAAarch研究小组进一步工作的起点。这项工作仍在进行中
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.
并发布，以便AAAarch小组和该领域的其他工作人员可以使用该工作，而不是作为架构或需求的最终描述。
The authorization subgroup of the AAA Working Group proposed an "AAA Authorization Framework" [2] illustrated with numerous application examples [3] which in turn motivates a proposed list of authorization requirements [4]. This memo builds on the framework presented in [2] by proposing an AAA infrastructure consisting of a network of cooperating generic AAA servers communicating via a standard protocol. The protocol should be quite general and should support the needs of a wide variety of applications requiring AAA functionality. To realize this goal, the protocol will need to operate in a multi-domain environment with multiple service providers as well as entities taking on other AAA roles such as User Home Organizations and brokers. It should be possible to combine requests for multiple authorizations of different types in the same authorization transaction. The AAA infrastructure will be required to forward the components of such requests to the appropriate AAA servers for authorization and to collect the authorization decisions from the various AAA servers consulted. All of this activity is perfectly general in nature and can be realized in the common infrastructure.
AAA工作组的授权小组提出了一个“AAA授权框架”[2]，并用大量应用示例[3]加以说明，这反过来又推动了授权要求的拟议列表[4]。本备忘录建立在[2]中提出的框架基础上，提出了一个AAA基础设施，由通过标准协议进行通信的合作通用AAA服务器网络组成。该协议应该非常通用，并且应该支持需要AAA功能的各种应用程序的需求。为了实现这一目标，该协议将需要在多域环境中运行，多个服务提供商以及承担其他AAA角色的实体，如用户家庭组织和代理。应该可以在同一授权事务中合并对不同类型的多个授权的请求。AAA基础设施需要将此类请求的组件转发到适当的AAA服务器进行授权，并从咨询的各种AAA服务器收集授权决策。所有这些活动本质上都是完全通用的，可以在公共基础设施中实现。
But the applications requiring AAA services will each have their own unique needs. After a service is authorized, it must be configured and initialized. This will require application specific knowledge and may require application specific protocols to communicate with application specific service components. To handle these application specific functions, we propose an application interface between a generic AAA server and a set of one or more Application Specific Modules (ASMs) which can carry out the unique functionality required by each application.
但需要AAA服务的应用程序将各有其独特的需求。授权服务后，必须对其进行配置和初始化。这将需要特定于应用程序的知识，并且可能需要特定于应用程序的协议来与特定于应用程序的服务组件通信。为了处理这些特定于应用程序的功能，我们提出了一个通用AAA服务器和一组或多个特定于应用程序的模块（ASM）之间的应用程序接口，这些模块可以执行每个应用程序所需的独特功能。
Since the data required by each application for authentication, authorization, or accounting may have unique structure, the standard AAA protocol should allow the encapsulation of opaque units of Application Specific Information (ASI). These units would begin with a standard header to allow them to be forwarded by the generic infrastructure. When delivered to the final destination, an ASI unit would be passed by a generic AAA server across its program interface to an appropriate ASM for application specific processing. Nevertheless, it remains a goal of the design for information units to be encoded in standard ways as much as possible so as to enable processing by a generic rule based engine.
由于每个应用程序用于身份验证、授权或记帐所需的数据可能具有独特的结构，因此标准AAA协议应允许封装应用程序特定信息（ASI）的不透明单元。这些单元将以一个标准头开始，以允许它们由通用基础设施转发。当交付到最终目的地时，ASI单元将由通用AAA服务器通过其程序接口传递给适当的ASM，以进行特定于应用程序的处理。然而，信息单元的设计目标仍然是尽可能以标准方式编码，以便能够通过基于规则的通用引擎进行处理。
The interactions of the generic AAA server with the Application Specific Modules and with each other to realize complex AAA functions is explored in section 2. Then, in section 3, we attempt to further organize the AAA functions into logical groups using a protocol layering abstraction. This abstraction is not intended to be a reference model ready to be used for protocol design. At this point in the work, there are numerous questions that need to be addressed and numerous problems that remain to be solved. It may be that an abstraction other than layering will prove to be more useful or, more likely, that the application layer will require some substructure of its own.
第2节探讨了通用AAA服务器与特定于应用程序的模块之间的交互以及为实现复杂的AAA功能而相互之间的交互。然后，在第3节中，我们尝试使用协议分层抽象将AAA函数进一步组织到逻辑组中。这个抽象并不打算成为一个可用于协议设计的参考模型。在这项工作中，有许多问题需要解决，还有许多问题有待解决。可能是分层以外的抽象将被证明更有用，或者更可能的是，应用层将需要自己的一些子结构。
Finally, in section 4, we show how the security requirements identified in [4] can be met in the generic server and the Application Specific Modules by applying security techniques such as public key encryption or digital signatures to the Application Specific Information units individually, so that different stakeholders in the AAA server network can protect selected information units from being deciphered or altered by other stakeholders in an authentication, authorization, or accounting chain.
最后，在第4节中，我们展示了如何通过将公钥加密或数字签名等安全技术分别应用于特定于应用程序的信息单元，在通用服务器和特定于应用程序的模块中满足[4]中确定的安全要求，因此，AAA服务器网络中的不同利益相关者可以保护选定的信息单元不被身份验证、授权或记帐链中的其他利益相关者解密或更改。
For the long term we envision a generic AAA server which is capable of authenticating users, handling authorization requests, and collecting accounting data. For a service provider, such a generic AAA server would be interfaced to an application specific module which manages the resource for which authorization is required. Generic AAA components would also be deployed in other administrative domains performing authorization functions.
从长远来看，我们设想一个通用的AAA服务器，它能够对用户进行身份验证、处理授权请求和收集记帐数据。对于服务提供商，此类通用AAA服务器将与特定于应用程序的模块接口，该模块管理需要授权的资源。通用AAA组件也将部署在执行授权功能的其他管理域中。
The first step in the authorization process is for the user or an entity operating on the user's behalf to submit a well-formatted request to an AAA server. A generic AAA server has rules (logic and/or algebraic formulas) to inspect the request and come to an authorization decision. The first problem which arises is that Application Specific Information (ASI) has to be separated from the underlying logic for the authorization. Ideally the AAA server would have a rule based engine at this point which would know the logic rules and understand some generic information in the request, but it would not know anything about application specific information except where this information can be evaluated to give a boolean or numerical value. It should be possible to create rules that refer to
授权过程的第一步是用户或代表用户操作的实体向AAA服务器提交格式良好的请求。通用AAA服务器有规则（逻辑和/或代数公式）来检查请求并做出授权决策。出现的第一个问题是，应用程序特定信息（ASI）必须与授权的底层逻辑分离。理想情况下，AAA服务器此时会有一个基于规则的引擎，该引擎会知道逻辑规则并理解请求中的一些通用信息，但它不会知道任何关于特定于应用程序的信息，除非可以对这些信息进行评估以给出布尔值或数值。应该可以创建引用的规则
data elements that were not considered when the application was created. For example, one could request to do a remote virtual control room experiment from home using a dialin provider. The request would only be successful if the dialin access server allows it and if there is bandwidth available (bandwidth broker) and if the experimenter has the money to pay for it (E-Commerce). Possibly the people who specified the bandwidth broker protocol did not think of combining quality of service with a network service authorization in a single AAA request, but this generic model would allow it.
创建应用程序时未考虑的数据元素。例如，可以请求使用拨号服务提供商在家中进行远程虚拟控制室实验。只有拨号接入服务器允许，并且有可用带宽（带宽代理），并且实验者有钱支付（电子商务），请求才会成功。指定带宽代理协议的人可能没有想到在单个AAA请求中结合服务质量和网络服务授权，但这种通用模型允许这样做。
+------+ +-------+ +-------+ +-------+ +-------+
| | auth | | auth | | auth | | auth | |
| |<---->| AAA |<---->| AAA |<---->| AAA |<---->| AAA |
| | | | | | | | | |
| | +-------+ +-------+ +-------+ +-------+
| User | | | | |
| | | +-------+ +-------+ +-------+
| | | | BB | | BB | |Budget |
| | | +-------+ +-------+ +-------+
| | | | |
| | +-------+ | |
| | |dial in| +-------+ +-------+
| |<====>|service|<====>|network|<====>|network|<===> Experiment
+------+ +-------+ +-------+ +-------+
+------+ +-------+ +-------+ +-------+ +-------+
| | auth | | auth | | auth | | auth | |
| |<---->| AAA |<---->| AAA |<---->| AAA |<---->| AAA |
| | | | | | | | | |
| | +-------+ +-------+ +-------+ +-------+
| User | | | | |
| | | +-------+ +-------+ +-------+
| | | | BB | | BB | |Budget |
| | | +-------+ +-------+ +-------+
| | | | |
| | +-------+ | |
| | |dial in| +-------+ +-------+
| |<====>|service|<====>|network|<====>|network|<===> Experiment
+------+ +-------+ +-------+ +-------+
user <-> dialin <-> backbone with BB <-> <remote experiment>
user <-> dialin <-> backbone with BB <-> <remote experiment>
Fig. 1 -- Example of a Multi Domain Multi Type of Server Request
图1——多域多类型服务器请求的示例
Ultimately an AAA server needs to interact with an application specific module (ASM). In a service provider, the ASM would manage resources and configure the service equipment to provide the authorized service. It might also involve itself in the authorization decision because it has the application specific knowledge required. A user home organization (UHO) may require ASMs as well, to perform application specific user authorization functions. For example, a UHO ASM might be required to access certain application specific databases or interpret application specific service level specifications.
最终，AAA服务器需要与特定于应用程序的模块（ASM）交互。在服务提供商中，ASM将管理资源并配置服务设备以提供授权服务。它还可能参与授权决策，因为它具有所需的特定于应用程序的知识。用户总部组织（UHO）也可能需要ASM来执行特定于应用程序的用户授权功能。例如，可能需要UHO ASM来访问特定于应用程序的数据库或解释特定于应用程序的服务级别规范。
Whatever the role of an administration relative to an authorization decision, the capabilities of the generic AAA server and the interface between it and the ASMs remains the same. This interface may be an Application Program Interface (API) or could even be a protocol based interface. In this model, however, the application
无论与授权决策相关的管理角色是什么，通用AAA服务器的功能及其与ASMs之间的接口都保持不变。该接口可以是应用程序接口（API），甚至可以是基于协议的接口。然而，在这个模型中，应用程序
specific module is regarded as as separate architectural component from the generic AAA server. As such, it must be addressable and must therefore be part of a global naming space.
特定模块被视为与通用AAA服务器分离的体系结构组件。因此，它必须是可寻址的，因此必须是全局命名空间的一部分。
For auditing purposes, the generic server must have some form of database to store time-stamped events which occur in the AAA server. This database can be used to account for authorizations which were given, but it can also be used in rules. One can imagine rules in which an authorization is only given if some other event was logged in the past. With the aid of certificates, this database could support non-repudiation.
出于审计目的，通用服务器必须具有某种形式的数据库来存储AAA服务器中发生的时间戳事件。该数据库可用于说明已授予的授权，但也可用于规则中。我们可以想象这样的规则：只有在过去记录了其他事件的情况下才授予授权。借助证书，该数据库可以支持不可否认性。
A database containing the available services and resources about which authorization decisions can be made and the policy rules to make them is also needed. Here too, the naming space for the services and resources is important since they must be addressable from other AAA servers to be able to build complex authorization requests.
还需要一个包含可用服务和资源的数据库，可以对这些服务和资源做出授权决策，以及制定授权决策的策略规则。在这里，服务和资源的命名空间也很重要，因为它们必须可以从其他AAA服务器寻址，才能生成复杂的授权请求。
Due to the multiple administrative domain (multi-kingdom) nature of the AAA problem, a mechanism to forward messages between AAA servers is needed. The protocol by which two AAA servers communicate should be a peer-to-peer protocol.
由于AAA问题的多管理域（多王国）性质，需要一种在AAA服务器之间转发消息的机制。两台AAA服务器进行通信的协议应为对等协议。
With the implementation of the above mentioned components, the AAA server would be able to handle AAA requests. It would inspect the contents of the request, determine what authorization is requested, retrieve the policy rules from the repository, perform various local functions, and then choose one of the following options to further process each of the components of the request:
通过实现上述组件，AAA服务器将能够处理AAA请求。它将检查请求的内容，确定请求的授权，从存储库检索策略规则，执行各种本地功能，然后选择以下选项之一进一步处理请求的每个组件：
a) Let the component be evaluated by an attached ASM.
a) 让组件由附加的ASM进行评估。
b) Query the authorization event log or the policy repository for the answer.
b) 查询授权事件日志或策略存储库以获取答案。
c) Forward the component(s) to another AAA server for evaluation.
c) 将组件转发到另一台AAA服务器进行评估。
In the following sections we present the generic model.
在以下部分中，我们将介绍通用模型。
Figure 2 illustrates a generic AAA Server with connections to the various architectural components described above. In this model, the user or another AAA server contacts the AAA server to get authorization, and the AAA server interacts with the service. The request is sent to the AAA server using the future AAA protocol. The server interacts with the service via a second protocol which we have labeled as type "2" in the figure. We say no more of the type 2 protocol than that it must support some global naming space for the application specific items. The same holds for the type 3 communication used to access the repository.
图2展示了一个通用AAA服务器，它连接到上述各种体系结构组件。在这个模型中，用户或另一个AAA服务器联系AAA服务器以获得授权，并且AAA服务器与服务交互。使用未来的AAA协议将请求发送到AAA服务器。服务器通过第二个协议与服务交互，我们在图中标记为类型“2”。我们只说类型2协议必须支持特定于应用程序的项的一些全局命名空间。用于访问存储库的类型3通信也是如此。
+------------------+
| |
request <-----1----->|Generic AAA Server|<---1---> AAA server
|Rule based engine |
| |\
+------------------+ 3 +------------+
^ \| Policy and |
| | event |
2 | repository |
| +------------+
v
+------------------+
| Application |
| Specific |
| Module |
+------------------+
+------------------+
| |
request <-----1----->|Generic AAA Server|<---1---> AAA server
|Rule based engine |
| |\
+------------------+ 3 +------------+
^ \| Policy and |
| | event |
2 | repository |
| +------------+
v
+------------------+
| Application |
| Specific |
| Module |
+------------------+
The numbers in the links denote types of communication.
链接中的数字表示通信类型。
Fig. 2 -- Generic AAA Server Interactions
图2——通用AAA服务器交互
Because of the widespread deployment of equipment that implements legacy AAA protocols and the desire to realize the functionality of the new AAA protocol while protecting the investment in existing infrastructure, it may be useful to implement a AAA gateway function that can encapsulate legacy protocol data units within the messages of the new protocol. Use of this technique, for example, would allow Radius attribute value pairs to be encapsulated in Application Specific Information (ASI) units of the new protocol in such a way that the ASI units can be digitally signed and encrypted for end-to-end protection between a service provider's AAA server and a home AAA server communicating via a marginally trusted proxy AAA server. The service provider's NAS would communicate via Radius to the service
由于实现传统AAA协议的设备的广泛部署，以及在保护现有基础设施投资的同时实现新AAA协议功能的愿望，实现AAA网关功能可能很有用，该功能可以将旧协议数据单元封装在新协议的消息中。例如，使用这种技术可以将Radius属性值对封装在特定于应用程序的信息（ASI）中新协议的单元，使得ASI单元可以进行数字签名和加密，以便在服务提供商的AAA服务器和家庭AAA服务器之间进行端到端保护，该家庭AAA服务器通过边缘受信任的代理AAA服务器进行通信。服务提供商的NAS将通过Radius与服务进行通信
provider's AAA server, but the AAA servers would communicate among themselves via the new AAA protocol. In this case, the AAA gateway would be a software module residing in the service provider's AAA server. Alternatively the AAA gateway could be implemented as a standalone process.
提供商的AAA服务器，但AAA服务器之间将通过新的AAA协议进行通信。在这种情况下，AAA网关将是驻留在服务提供商的AAA服务器中的软件模块。或者，AAA网关可以作为一个独立的进程来实现。
Figure 3 illustrates an AAA gateway. Communication type 4 is the legacy protocol. Communication type 1 is the future standard AAA protocol. And communication type 2 is for application specific communication to Application Specific Modules (ASMs) or Service Equipment.
图3展示了一个AAA网关。通信类型4是传统协议。通信类型1是未来的标准AAA协议。通信类型2用于与专用模块（ASM）或维修设备的专用通信。
+-------+
| AAA |<---1---> to AAA server as in fig. 2
request <---4--->|GateWay|
| |<---2---> optionally to ASM/service
+-------+
+-------+
| AAA |<---1---> to AAA server as in fig. 2
request <---4--->|GateWay|
| |<---2---> optionally to ASM/service
+-------+
The numbers in the links denote types of communication.
链接中的数字表示通信类型。
Fig. 3 -- AAA Gateway for Legacy AAA Protocols
图3——传统AAA协议的AAA网关
In a service provider, the Application Specific Module (ASM) and the software providing the service itself may be tightly bound into a single "Service Application". In this case, the interface between them is just a software interface. But the service itself may be provided by equipment external to the ASM, for example, a router in the bandwidth broker application. In this case, the ASM communicates with the service via some protocol. These two possibilities are illustrated in figure 4. In both cases, we have labeled the communication between the ASM and the service as communication type 5, which of course, is service specific.
在服务提供商中，特定于应用程序的模块（ASM）和提供服务本身的软件可以紧密绑定到单个“服务应用程序”中。在这种情况下，它们之间的接口只是一个软件接口。但是服务本身可以由ASM外部的设备提供，例如，带宽代理应用程序中的路由器。在这种情况下，ASM通过某种协议与服务通信。这两种可能性如图4所示。在这两种情况下，我们都将ASM和服务之间的通信标记为通信类型5，这当然是特定于服务的。
| |
+--------------|----+ |
| Service 2 | 2
| Application | | |
| +-------------+ | +-------------+
| | Application | | | Application |
| | Specific | | | Specific |
| | Module | | | Module |
| +-------------+ | +-------------+
| | | |
| 5 | 5
| | | |
| +-------------+ | +-------------+
| | Service | | | Service |
| | | | | Equipment |
| +-------------+ | +-------------+
+-------------------+
| |
+--------------|----+ |
| Service 2 | 2
| Application | | |
| +-------------+ | +-------------+
| | Application | | | Application |
| | Specific | | | Specific |
| | Module | | | Module |
| +-------------+ | +-------------+
| | | |
| 5 | 5
| | | |
| +-------------+ | +-------------+
| | Service | | | Service |
| | | | | Equipment |
| +-------------+ | +-------------+
+-------------------+
Fig. 4 -- ASM to Service Interaction (two views)
图4——ASM与服务的交互（两个视图）
The generic AAA server modules can use communication type 1 to contact each other to evaluate parts of requests. Figure 5 illustrates a network of generic AAA servers in different administrative domains communicating via communication type 1.
通用AAA服务器模块可以使用通信类型1相互联系以评估部分请求。图5显示了不同管理域中通过通信类型1进行通信的通用AAA服务器网络。
+-----+
o--------| AAA |---->...
/ | |
/ +-----+\
/ | \+----+
/ +-----+ | RP |
/ | ASM | +----+
+--------+ +-----+ / | |
| Client |------| AAA |-------o +-----+
+--------+ | | \
+-----+ \
| +----+ \ +-----+
+-----+ | RP | o-----| AAA |---->...
| ASM | +----+ | |
| | +-----+\
+-----+ | \+----+
+-----+ | RP |
| ASM | +----+
| |
+-----+
+-----+
o--------| AAA |---->...
/ | |
/ +-----+\
/ | \+----+
/ +-----+ | RP |
/ | ASM | +----+
+--------+ +-----+ / | |
| Client |------| AAA |-------o +-----+
+--------+ | | \
+-----+ \
| +----+ \ +-----+
+-----+ | RP | o-----| AAA |---->...
| ASM | +----+ | |
| | +-----+\
+-----+ | \+----+
+-----+ | RP |
| ASM | +----+
| |
+-----+
The AAA servers use only communication type 1 to communicate. ASM = Application Specific Module RP = Repository
AAA服务器仅使用通信类型1进行通信。ASM=特定于应用程序的模块RP=存储库
Fig. 5 -- Multi-domain Multi-type of Service Architecture
图5——多域多类型服务体系结构
Some key points of the generic architecture are:
通用体系结构的一些关键点包括：
1) The same generic AAA server can function in all three authorization models: agent, pull, and push [2].
1) 相同的通用AAA服务器可以在所有三种授权模型中运行：代理、拉和推[2]。
2) The rule based engine knows how to evaluate logical formulas and how to parse AAA requests.
2) 基于规则的引擎知道如何计算逻辑公式以及如何解析AAA请求。
3) The Generic AAA server has no knowledge whatsoever about the application specific services so the application specific information it forwards is opaque to it.
3) 通用AAA服务器对特定于应用程序的服务一无所知，因此它转发的特定于应用程序的信息对它来说是不透明的。
4) Communication types 1, 2, and 3 each present their own naming space problems. Solving these problems is fundamental to forwarding AAA messages, locating application specific entities, and locating applicable rules in the rule repositories.
4) 通信类型1、2和3各有各自的命名空间问题。解决这些问题是转发AAA消息、定位特定于应用程序的实体以及在规则存储库中定位适用规则的基础。
5) A standard AAA protocol for use in communication type 1 should be a peer-to-peer protocol without imposing client and server roles on the communicating entities.
5) 在通信类型1中使用的标准AAA协议应为对等协议，而不会对通信实体施加客户端和服务器角色。
6) A standard AAA protocol should allow information units for multiple different services belonging to multiple different applications in multiple different administrative domains to be combined in a single AAA protocol message.
6) 标准AAA协议应允许在单个AAA协议消息中组合属于多个不同管理域中多个不同应用程序的多个不同服务的信息单元。
It is hoped that by using this generic model it will be feasible to design a AAA protocol that is "future proof", in a sense, because much of what we do not think about now can be encoded as application specific information and referenced by policy rules stored in a policy repository. From this model, some generic requirements arise that will require some further study. For example, suppose a new user is told that somewhere on a specific AAA server a certain authorization can be obtained. The user will need a AAA protocol that can:
我们希望，通过使用这种通用模型，设计一个AAA协议将是可行的，在某种意义上说，它是“未来的证明”，因为我们现在没有想到的很多内容都可以编码为特定于应用程序的信息，并由存储在策略存储库中的策略规则引用。从这个模型中，出现了一些需要进一步研究的通用需求。例如，假设一个新用户被告知可以在特定AAA服务器上的某个地方获得某种授权。用户需要AAA协议，该协议可以：
1) send a query to find out which authorizations can be obtained from a specific server,
1) 发送查询以了解可以从特定服务器获得哪些授权，
2) provide a mechanism for determining what components must be put in an AAA request for a specific authorization, and
2) 提供一种机制，用于确定特定授权的AAA请求中必须放置哪些组件，以及
3) formulate and transmit the authorization request.
3) 制定并发送授权请求。
Some areas where further work is particularly needed are in identifying and designing the generic components of a AAA protocol and in determining the basis upon which component forwarding and policy retrieval decisions are made.
特别需要进一步工作的一些领域是识别和设计AAA协议的通用组件，以及确定组件转发和策略检索决策的基础。
In addition to these areas, there is a need to explore the management of rules in a multi-domain AAA environment because the development and future deployment of a generic multi-domain AAA infrastructure is largely dependent on its manageability. Multi-domain AAA environments housing many rules distributed over several AAA servers quickly become unmanageable if there is not some form of automated rule creation and housekeeping. Organizations that allow their services to be governed by rules, based on some form of commercial contract, require the contract to be implemented with the least
除这些领域外，还需要探索多域AAA环境中的规则管理，因为通用多域AAA基础设施的开发和未来部署在很大程度上取决于其可管理性。如果没有某种形式的自动规则创建和内务管理，多域AAA环境中包含分布在多个AAA服务器上的许多规则，将很快变得难以管理。允许其服务受基于某种形式的商业合同的规则管辖的组织，要求以最少的成本实施合同
possible effort. This can, for example, be achieved in a scalable fashion if the individual user or user organization requesting a service is able to establish the service itself. This kind of interaction requires policy rule establishment between AAA servers belonging to multiple autonomous administrative domains.
可能的努力。例如，如果请求服务的单个用户或用户组织能够建立服务本身，则这可以以可伸缩的方式实现。这种交互需要在属于多个自治管理域的AAA服务器之间建立策略规则。
In the previous section, we proposed the idea of a generic AAA server with an interface to one or more Application Specific Modules (ASMs). The generic server would handle many common functions including the forwarding of AAA messages between servers in different administrative domains. We envision message transport, hop-by-hop security, and message forwarding as clearly being functions of the generic server. The application specific modules would handle all application specific tasks such as communication with service equipment and access to special purpose databases. Between these two sets of functions is another set of functions that presumably could take place in either the generic server or an ASM or possibly by a collaboration of both. These functions include the evaluation of authorization rules against data that may reside in various places including attributes from the authorization request itself. The more we can push these functions down into the generic server, the more powerful the generic server can be and the simpler the ASMs can be.
在上一节中，我们提出了通用AAA服务器的概念，该服务器具有一个或多个特定于应用程序的模块（ASM）的接口。通用服务器将处理许多常见功能，包括在不同管理域的服务器之间转发AAA消息。我们设想消息传输、逐跳安全性和消息转发显然是通用服务器的功能。特定于应用程序的模块将处理所有特定于应用程序的任务，如与服务设备通信和访问专用数据库。在这两组函数之间是另一组函数，可能发生在通用服务器或ASM中，也可能发生在两者的协作中。这些功能包括根据可能位于不同位置的数据（包括授权请求本身的属性）评估授权规则。我们将这些功能下推到通用服务器中的次数越多，通用服务器的功能就越强大，ASMs就越简单。
One way of organizing the different functions mentioned above would be to assign them to a layered hierarchy. In fact, we have found the layer paradigm to be a useful one in understanding AAA functionality. This section explores the use of a layered hierarchy consisting of the following AAA layers as a way of organizing the AAA functions:
组织上述不同功能的一种方法是将它们分配到分层层次结构中。事实上，我们发现层范例在理解AAA功能方面非常有用。本节探讨如何使用由以下AAA层组成的分层层次结构来组织AAA功能：
Application Specific Service Layer Presentation Service Layer Transaction/Session Management Service Layer Reliable/Secure Transport Service Layer
特定于应用程序的服务层表示服务层事务/会话管理服务层可靠/安全传输服务层
Nevertheless, the interface between the generic AAA server and the ASMs proposed in the previous section may be more complex than a simple layered model would allow. Even the division of functionality proposed in this section goes beyond a strict understanding of layering. Therefore this paper can probably best be understood as the beginnings of a work to understand and organize the common functionality required for a general purpose AAA infrastructure rather than as a mature reference model for the creation of AAA protocols.
然而，通用AAA服务器和上一节中提出的ASM之间的接口可能比简单的分层模型所允许的更复杂。甚至本节中提出的功能划分也超出了对分层的严格理解。因此，最好将本文理解为理解和组织通用AAA基础设施所需的通用功能的开始，而不是创建AAA协议的成熟参考模型。
In our view of AAA services modeled as a hierarchy of service layers, there is a set of distributed processes at each service layer that cooperate and are responsible for implementing that service layer's functions. These processes communicate with each other using a protocol specialized to carry out the functions and responsibilities assigned to their service layer. The protocol at service layer n communicates to its peers by depending on the services available to it from service layer n-1. The service layer n also has a protocol end point address space, through which the peer processes at service layer n can send messages to each other. Together, these AAA service layers can be assembled into an AAA protocol stack.
在我们看来，AAA服务被建模为服务层的层次结构，每个服务层都有一组分布式进程，它们相互协作并负责实现该服务层的功能。这些流程使用专门用于执行分配给其服务层的功能和职责的协议相互通信。服务层n的协议通过依赖于服务层n-1提供给它的服务来与其对等方通信。服务层n还具有协议端点地址空间，通过该地址空间，服务层n的对等进程可以彼此发送消息。这些AAA服务层可以组合成一个AAA协议栈。
The advantage of this approach is that there is not just one monolithic "AAA protocol". Instead there is a suite of protocols, and each one is optimized to solve the problems found at its layer of the AAA protocol stack hierarchy.
这种方法的优点是，不只是一个单一的“AAA协议”。取而代之的是一套协议，每一套协议都经过优化，以解决AAA协议栈层次结构中的问题。
This approach realizes several key benefits:
这种方法实现了几个关键好处：
- The protocol used at any particular layer in the protocol stack can be substituted for another functionally equivalent protocol without disrupting the services in adjacent layers.
- 协议栈中任何特定层使用的协议可以替换为另一个功能等效的协议，而不会中断相邻层中的服务。
- Requirements in one layer may be met without impact on protocols operating in other layers. For example, local security requirements may dictate the substitution of stronger or weaker "reliable secure transport" layer security algorithms or protocols. These can be introduced with no change or awareness of the substitution by the layers above the Reliable/Secure Transport layer.
- 一层中的需求可以在不影响其他层中的协议的情况下得到满足。例如，本地安全需求可能要求替换更强或更弱的“可靠安全传输”层安全算法或协议。这些可以在不改变或不知道可靠/安全传输层之上的层的替换的情况下引入。
- The protocol used for a given layer is simpler because it is focused on a specific narrow problem that is assigned to its service layer. In particular, it should be feasible to leverage existing protocol designs for some aspects of this protocol stack (e.g. CORBA GIOP/CDR for the presentation layer).
- 用于给定层的协议更简单，因为它专注于分配给其服务层的特定狭窄问题。特别是，对于该协议栈的某些方面（例如，表示层的CORBA GIOP/CDR），利用现有协议设计应该是可行的。
- A legacy AAA protocol message (e.g. a RADIUS message) can be encapsulated within the protocol message(s) of a lower layer protocol, preserving the investment of a Service Provider or User Home Organization in their existing AAA infrastructure.
- 传统AAA协议消息（例如RADIUS消息）可封装在较低层协议的协议消息内，从而保护服务提供商或用户总部组织在其现有AAA基础设施中的投资。
- At each service layer, a suite of alternatives can be designed, and the service layer above it can choose which alternative makes sense for a given application. However, it should be a primary goal of the AAA protocol standardization effort to specify one mandatory to implement protocol at the AAA Transaction/Session Management (AAA-TSM) service layer (see section 3.4).
- 在每个服务层，都可以设计一套备选方案，其上的服务层可以选择对给定应用程序有意义的备选方案。然而，AAA协议标准化工作的主要目标应该是指定一个在AAA事务/会话管理（AAA-TSM）服务层实现协议的强制性协议（见第3.4节）。
At each layer of a layered architecture, a number of elements need to be defined. These elements are discussed in the following sections.
在分层体系结构的每一层，都需要定义许多元素。以下各节将讨论这些要素。
The service layer n is assumed to present a program interface through which its adjacent service layer n+1 can access its services. The types of abstract program service primitives and associated parameters exchanged across the boundary between these service layers must be specified.
假定服务层n呈现一个程序接口，其相邻服务层n+1可通过该程序接口访问其服务。必须指定抽象程序服务原语的类型以及在这些服务层之间的边界上交换的相关参数。
Each service layer is treated as a set of cooperating processes distributed across multiple computing systems. The service layer must manage an end point name space that identifies these peer processes. The conventions by which a service layer assigns a unique end point name to each such peer process must be specified.
每个服务层被视为分布在多个计算系统中的一组协作进程。服务层必须管理标识这些对等进程的端点名称空间。必须指定服务层为每个对等进程分配唯一端点名称的约定。
Along with defining an end point name space, a service layer must also specify how its peers:
除了定义端点名称空间，服务层还必须指定其对等方如何：
- announce their presence and availability,
- 宣布他们的存在和可用性，
- discover one another when they first begin operation, and
- 在他们第一次开始操作时相互发现，以及
- detect loss of connectivity or service withdrawal.
- 检测连接丢失或服务退出。
It is also necessary to specify what mechanisms, if any, exist to resolve a set of service layer specific search attributes into one or more peer end point names that match the search criteria.
还需要指定存在哪些机制（如果有的话）来将一组特定于服务层的搜索属性解析为一个或多个匹配搜索条件的对等端点名称。
Once an end point has established its initial contact with another peer, it must decide what authentication policy to adapt. It can trust whatever authentication was done on its behalf by a lower service layer or, through a pre-provisioning process, implicitly trust the peer, or else go through an authentication process with its peer. The supported mechanisms for establishing a service layer's end point trust relationships must be specified.
一旦一个端点与另一个对等点建立了初始联系，它就必须决定采用何种身份验证策略。它可以信任由较低的服务层代表其进行的任何身份验证，或者通过预配置过程，隐式信任对等方，或者通过与对等方的身份验证过程。必须指定用于建立服务层端点信任关系的支持机制。
To the extent that a service layer's internal states are externally visible, the layer's behavior in terms of a Finite State Machine (FSM) should be specified. Events that can drive the FSM state transitions may include:
如果服务层的内部状态在外部可见，则应指定该层在有限状态机（FSM）方面的行为。可驱动FSM状态转换的事件可能包括：
- service layer n+1 interface primitive requests
- 服务层n+1接口基本请求
- protocol data unit arrivals from peer service layer n end points received through the layer n-1 access point
- 通过层n-1接入点接收来自对等服务层n端点的协议数据单元到达
- service layer n-1 interface primitives (e.g. call backs or interrupts)
- 服务层n-1接口原语（例如回调或中断）
- timer expirations
- 计时器过期
Each service layer defines a lexicon of protocol data units (PDUs) that communicate between the layer's peer processes the information that controls and/or monitors that service layer's distributed state and allows the service processes of that layer to perform their functions. Embedded in the PDUs of each layer are the PDUs of the higher layers which depend on its services. The PDUs of each service layer must be specified.
每个服务层定义了协议数据单元（PDU）的词典，这些协议数据单元（PDU）在层的对等进程之间进行通信，这些信息控制和/或监视该服务层的分布式状态，并允许该层的服务进程执行其功能。在每一层的PDU中嵌入的是依赖于其服务的更高层的PDU。必须指定每个服务层的PDU。
AAA applications have almost unlimited diversity, but imposing some constraints and commonality is required for them to participate in this generic AAA architectural framework. To satisfy these constraints, participating AAA applications would derive their application specific program logic from a standardized "Authorization Server" abstract base object class. They would also support an "Authorized Session" object class. An Authorization Session object instance represents an approved authorization request that has a long-lived allocation of services or resources. The generic AAA architecture could be extended to include other abstract base object classes in the future (e.g. Authorization Reservation, Authentication Server, etc.). How to implement the derived Authorization Server class's public methods for a given problem domain is entirely up to the application. One technique might be to place a software "wrapper" around an existing embedded application specific service to adapt it to the standardized Authorization Server object paradigm. The major Authorization Server class methods are:
AAA应用程序几乎具有无限的多样性，但要使它们参与到这个通用的AAA体系结构框架中，需要施加一些约束和通用性。为了满足这些约束，参与的AAA应用程序将从标准化的“授权服务器”抽象基本对象类派生其特定于应用程序的程序逻辑。它们还支持“授权会话”对象类。授权会话对象实例表示具有长期服务或资源分配的已批准授权请求。通用AAA体系结构可以在将来扩展到包括其他抽象基本对象类（例如授权保留、身份验证服务器等）。如何为给定的问题域实现派生授权服务器类的公共方法完全取决于应用程序。一种技术可能是在现有嵌入式应用程序特定服务周围放置软件“包装器”，以使其适应标准化的授权服务器对象范例。主要的授权服务器类方法有：
- Publish an advertisement that describes the Authorization Server's service attributes and its application specific service layer end point address. Once the Authorization Server has registered, peer processes can discover its presence or send messages addressed to it.
- 发布描述授权服务器的服务属性及其特定于应用程序的服务层端点地址的公告。一旦授权服务器注册，对等进程就可以发现它的存在或向它发送消息。
- Application Specific Authorization Decision Function (AS-ADF) method takes a User's application specific authorization request and returns a decision of approve, deny, or conditionally approve with referral to another stakeholder. In the latter case, the application may create a reservation for the requested services or resources. This method represents the "condition" side of a policy rule's condition/action pair.
- 特定于应用程序的授权决策函数（AS-ADF）方法接受用户特定于应用程序的授权请求，并返回批准、拒绝或有条件批准的决策，并将其提交给其他干系人。在后一种情况下，应用程序可以为请求的服务或资源创建保留。此方法表示策略规则的条件/操作对的“条件”端。
- Commit a service or set of resources to a previously conditionally approved authorization decision. For those authorization requests that have a long-term lifecycle (as opposed to being transactions), this method mobilizes a reservation into an Authorized Session object instance. This method represents the "action" side of a policy rule's condition/action pair.
- 将服务或资源集提交给先前有条件批准的授权决策。对于那些具有长期生命周期（而不是事务）的授权请求，此方法将保留移动到授权会话对象实例中。此方法表示策略规则的条件/操作对的“操作”端。
- Cancel a previously conditionally approved Authorization request. This method releases any associated reservations for services or resources.
- 取消以前有条件批准的授权请求。此方法释放服务或资源的任何关联保留。
- Withdraw the Authorization Server's service advertisement.
- 撤消授权服务器的服务播发。
A key motivation for structuring an AAA application as an Authorization Server object instance is to separate the generic authorization decision logic from the application-specific authorization decision logic. In many cases, the application can be divorced from the AAA problem altogether, and its AAA responsibility can be assigned to an external rules based generic AAA Server. (The idea is similar to that of a trust management policy server as defined in [5].) This would facilitate a security administrator deploying AAA policy in a central repository. The AAA policy is applied consistently across all users of the applications, resources, and services controlled by the AAA server. However, it is recognized that for many problem domains, there are unique rules intrinsic to the application. In these cases, the generic AAA Server must refer the User's authorization request to the relevant Application Specific Module.
将AAA应用程序构造为授权服务器对象实例的一个关键动机是将通用授权决策逻辑与特定于应用程序的授权决策逻辑分离。在许多情况下，应用程序可以完全脱离AAA问题，其AAA责任可以分配给基于外部规则的通用AAA服务器。（这个想法类似于[5]中定义的信任管理策略服务器）。这将有助于安全管理员在中央存储库中部署AAA策略。AAA策略在由AAA服务器控制的应用程序、资源和服务的所有用户中一致应用。然而，人们认识到，对于许多问题域，应用程序都有其固有的独特规则。在这些情况下，通用AAA服务器必须将用户的授权请求提交给相关的特定于应用程序的模块。
The presentation service layer solves the data representation problems that are encountered when communicating peers exchange complex data structures or objects between their heterogeneous
表示服务层解决了在通信对等方之间交换复杂数据结构或对象时遇到的数据表示问题
computing systems. The goal is to transfer semantically equivalent application layer data structures regardless of the local machine architecture, operating system, compiler, or other potential inter-system differences.
计算系统。目标是传输语义等价的应用层数据结构，而不考虑本地机器体系结构、操作系统、编译器或其他潜在的系统间差异。
One way to better understand the role of the presentation layer is to evaluate an existing example. The Generic Inter-ORB Protocol (GIOP) and its Common Data Representation (CDR) is a presentation service layer protocol developed by the Object Management Group (OMG) industry consortium. GIOP is one component within the Common Object Request Broker Architecture (CORBA). Peer Object Request Brokers (ORB) executing on heterogeneous systems use GIOP to invoke remote CORBA object interface methods. GIOP encodes an object method's input and output parameters in the Common Data Representation (CDR). While there are other presentation service layer protocols in the industry, GIOP in combination with CDR represents a mature, comprehensive solution that exhibits many of the presentation service layer requirements that are applicable within the AAA protocol model.
更好地理解表示层角色的一种方法是评估现有示例。通用ORB间协议（GIOP）及其公共数据表示（CDR）是由对象管理集团（OMG）行业联盟开发的表示服务层协议。GIOP是公共对象请求代理体系结构（CORBA）中的一个组件。在异构系统上执行的对等对象请求代理（ORB）使用GIOP调用远程CORBA对象接口方法。GIOP在公共数据表示（CDR）中对对象方法的输入和输出参数进行编码。虽然业界还有其他表示服务层协议，但GIOP与CDR的结合代表了一个成熟、全面的解决方案，它展示了适用于AAA协议模型的许多表示服务层要求。
In the context of Internet access AAA protocols, RADIUS and its successors use the Attribute Value Pair (AVP) paradigm as the presentation service layer encoding scheme. While such an approach is versatile, it is also prone to becoming splintered into many ad hoc and vendor specific dialects. There is no structure imposed or method to negotiate the constraints on which AVPs are combined and interpreted for a given conversation in a consistent way across AAA protocol implementations or problem domains. At run-time, it can be hard for the communicating peers to negotiate to a common inter-operable set of AVPs.
在Internet访问AAA协议的上下文中，RADIUS及其后续协议使用属性值对（AVP）范式作为表示服务层编码方案。虽然这种方法是多功能的，但它也容易分裂成许多特殊的和特定于供应商的方言。在AAA协议实现或问题域中，没有强制的结构或方法来协商AVP组合和解释给定对话的约束条件。在运行时，通信对等方很难协商到一组通用的可互操作AVP。
To avoid this pitfall, a primary presentation service layer responsibility is the ability to let peers negotiate from a base Authorization Server object class towards a commonly understood derived Authorization Server object class that both presentation service layer peers have implemented for their application specific problem domain. This negotiation implies a requirement for a globally registered and maintained presentation service layer hierarchy of Authorization Server object class names.
为了避免这个陷阱，表示服务层的主要职责是让对等方能够从基本授权服务器对象类协商到通常理解的派生授权服务器对象类，这两个表示服务层对等方都为其特定于应用程序的问题域实现了该类。此协商意味着需要全局注册和维护授权服务器对象类名的表示服务层层次结构。
The AAA Transaction/Session Management (AAA-TSM) service layer is a distributed set of AAA Servers, which typically reside in different administrative domains. Collectively they are responsible for the following three services:
AAA事务/会话管理（AAA-TSM）服务层是一组分布的AAA服务器，通常位于不同的管理域中。他们共同负责以下三项服务：
Authentication -- Execute the procedure(s) needed to confirm the identity of the other parties with which the AAA TSM entity has a trust relationship.
身份验证--执行确认AAA TSM实体与之具有信任关系的其他方的身份所需的过程。
Authorization -- Make an authorization decision to grant or deny a User's request for services or resources. The generic rules based policy engine described earlier in this document executes the authorization decision function. When the User's request is instantaneous and transient, then its authorization approval is treated as an ephemeral transaction. If the authorization approval implies a sustained consumption of a service or resources, then the request is transformed into an Authorized Session. For the duration of the Authorized Session's lifetime:
授权——做出授权决定以批准或拒绝用户对服务或资源的请求。本文档前面描述的基于通用规则的策略引擎执行授权决策功能。当用户的请求是瞬时的和暂时的时，其授权批准被视为短暂的事务。如果授权批准意味着持续消耗服务或资源，那么请求将转换为授权会话。在授权会话的生存期内：
- its state may be queried and reported, or
- 可以查询和报告其状态，或者
- it may be canceled before service is completed, or
- 可能在服务完成前取消，或者
- the service being delivered may be modified to operate under new parameters and conditions, or
- 正在交付的服务可能会被修改为在新的参数和条件下运行，或者
- the service may complete on its own accord.
- 服务可自行完成。
In each of these cases, the AAA-TSM service layer must synchronize the Authorized Session's distributed state across all of those AAA Servers which are implementing that specific Authorized Session.
在每种情况下，AAA-TSM服务层都必须在所有实现特定授权会话的AAA服务器上同步授权会话的分布式状态。
Accounting -- Generate any relevant accounting information regarding the authorization decision and the associated Authorized Session (if any) that represents the ongoing consumption of those services or resources.
记帐--生成有关授权决策和相关授权会话（如果有）的任何相关记帐信息，这些信息表示这些服务或资源的持续消耗。
The peer AAA servers and their AAA-TSM end points exchange AAA-TSM messages to realize these AAA functions. A central AAA-TSM concept is that there is a set of one or more AAA Server stakeholders who are solicited to approve/disapprove a User request for application layer services. The AAA-TSM service layer routes the User's request from one stakeholder to the next, accumulating the requisite approvals until they have all been asked to make an authorization decision.
对等AAA服务器及其AAA-TSM端点交换AAA-TSM消息以实现这些AAA功能。AAA-TSM的一个核心概念是，有一组一个或多个AAA服务器涉众被请求批准/不批准用户对应用层服务的请求。AAA-TSM服务层将用户的请求从一个干系人路由到下一个干系人，累积必要的批准，直到所有干系人都被要求做出授权决策。
The AAA Servers may also do User authentication (or re-authentication) as part of this approval process. The overall flow of the routing from one stakeholder to another may take the form of the "push", "pull", or "agent" authorization models developed in [2]. However, in principle, it is feasible to have an arbitrary routing path of an AAA-TSM authorization request among stakeholders. Once the final approval is received, the AAA-TSM service layer commits the requested service by notifying all of those stakeholders that require
AAA服务器还可以进行用户身份验证（或重新身份验证），作为此批准流程的一部分。从一个干系人到另一个干系人的路由的整体流程可以采用[2]中开发的“推”、“拉”或“代理”授权模型的形式。然而，原则上，在利益相关者之间拥有AAA-TSM授权请求的任意路由路径是可行的。一旦收到最终批准，AAA-TSM服务层通过通知所有需要的涉众来提交请求的服务
a confirmation (i.e. turn on a pending reservation and do a transaction commit). Alternatively, any stakeholder among those on the consent list can veto the authorization request. In that case, all stakeholders who previously approved the request and had asked for a confirmation are told that the request has been denied (i.e., cancel reservation and do a transaction rollback).
确认（即打开挂起的保留并执行事务提交）。或者，同意名单上的任何利益相关者都可以否决授权请求。在这种情况下，所有先前批准请求并要求确认的利益相关者都会被告知请求已被拒绝（即取消预订并执行事务回滚）。
The AAA-TSM authorization request payload must carry its own "Context State", such that when an AAA server receives it, there is sufficient information that it is essentially self-contained. Embedding the Context State within the AAA-TSM message provides two benefits. First, the message can be immediately processed with respect to the AAA Server's local policy, and this minimizes or altogether avoids the need for the AAA Server to exchange additional AAA-TSM messages with its peers to complete its piece of the overall authorization decision. The other benefit is that the AAA Server minimizes the amount of state information resources that it commits to a user's pending request until it is fully approved. This helps protect against denial of service attacks.
AAA-TSM授权请求有效负载必须具有自己的“上下文状态”，这样当AAA服务器接收到它时，就有足够的信息表明它基本上是自包含的。在AAA-TSM消息中嵌入上下文状态有两个好处。首先，可以根据AAA服务器的本地策略立即处理消息，这将最小化或完全避免AAA服务器需要与其对等方交换额外的AAA-TSM消息以完成其整体授权决策。另一个好处是，AAA服务器可以最大限度地减少提交给用户的挂起请求的状态信息资源量，直到完全批准为止。这有助于防止拒绝服务攻击。
One can envision many possible message elements that could be part of the Context State carried within an AAA-TSM request message:
我们可以设想许多可能的消息元素，这些元素可能是AAA-TSM请求消息中携带的上下文状态的一部分：
- AAA-TSM session identifier, a unique handle representing this authorization request. All AAA servers who participate in a request's approval process and its subsequent monitoring throughout its Session lifetime refer to this handle.
- AAA-TSM会话标识符，表示此授权请求的唯一句柄。所有参与请求审批流程及其在会话生命周期内的后续监控的AAA服务器都引用此句柄。
- permission lists stating which AAA Servers are allowed to modify which parts of the message.
- 权限列表，说明允许哪些AAA服务器修改消息的哪些部分。
- User's authorization request, encoded as a presentation layer PDU.
- 用户的授权请求，编码为表示层PDU。
- User authentication information, (e.g. an X.509 public key certificate).
- 用户身份验证信息（例如X.509公钥证书）。
- User credentials information, or else a pointer to where that information can be found by an AAA server. An example of such credentials would be an X.509 attributes certificate.
- 用户凭据信息，或指向AAA服务器可在何处找到该信息的指针。此类凭证的一个示例是X.509属性证书。
- the list of AAA Server stakeholders who have yet to be visited to gain full approval of the User's authorization request. Each element in that list contains a presentation layer message encoding how the user authorization request should be evaluated by its application specific Authorization Decision Function (ADF).
- 尚未访问以获得用户授权请求完全批准的AAA服务器涉众列表。该列表中的每个元素都包含一个表示层消息，该消息编码用户授权请求应如何通过其特定于应用程序的授权决策功能（ADF）进行评估。
- the current position in the list of AAA Server stakeholders to be visited.
- 要访问的AAA服务器涉众列表中的当前位置。
- a list of those AAA servers which have already conditionally approved the User's authorization request, but which have predicated their approval on the request also completing its approval from those stakeholders who have not yet seen the request. Each element in the list has a digital signature or comparable mechanism by which their approval can be subsequently verified.
- 已有条件批准用户授权请求的AAA服务器的列表，但这些服务器已根据请求预测其批准，并已完成尚未看到该请求的利益相关者的批准。清单中的每一个要素都有一个数字签名或类似的机制，通过该机制可以随后核实其批准情况。
- an expiration time stamp, expressed in a universally understood time reference, which sets a lifetime limit on the AAA-TSM message's validity. This offers some replay attack protection, and inhibits messages from circulating indefinitely seeking the completion of a request's approval.
- 以普遍理解的时间引用表示的过期时间戳，它设置AAA-TSM消息有效性的生存期限制。这提供了一些重播攻击保护，并禁止消息无限期地传播以寻求请求批准的完成。
- a message payload modification audit trail, tracing which parties introduced changes into the User's authorization request terms and conditions.
- 消息有效负载修改审计跟踪，跟踪哪些方对用户的授权请求条款和条件进行了更改。
- an AAA-TSM message integrity check, computed across the whole message rather than its individual elements, and signed by the most recent AAA-TSM layer end point process to modify the AAA-TSM message before its transmission to its AAA-TSM peer. This function may be delegated to the underlying Reliable Secure Transport layer connection to that destination peer.
- AAA-TSM消息完整性检查，跨整个消息而不是其单个元素计算，并由最新的AAA-TSM层端点进程签名，以在将AAA-TSM消息传输到其AAA-TSM对等方之前修改AAA-TSM消息。此功能可以委托给与该目标对等方的底层可靠安全传输层连接。
The AAA-TSM service layer and its adjacent presentation service layer communicate across their boundary through a set of program interface primitives. A key design goal is to keep these primitives the same regardless of the higher level AAA application, analogous to a callable "plug-in". The two service layers are responsible for coordinating their state information. This responsibility includes all of the pending Authorization requests and the Authorization Sessions that they are both controlling and monitoring. The initial contact between these two layers is through an abstract object that is called an AAA-TSM Service Access Point (SAP). A particular service instance between these two layers is realized in an abstract object that is called an Authorized Session. The presentation service layer invokes AAA-TSM interface primitives against an AAA-TSM SAP.
AAA-TSM服务层及其相邻的表示服务层通过一组程序接口原语跨边界通信。一个关键的设计目标是使这些原语保持不变，而不考虑更高级别的AAA应用程序，类似于可调用的“插件”。这两个服务层负责协调它们的状态信息。此职责包括所有挂起的授权请求及其控制和监视的授权会话。这两个层之间的初始接触是通过一个称为AAA-TSM服务访问点（SAP）的抽象对象进行的。这两层之间的特定服务实例在一个称为授权会话的抽象对象中实现。表示服务层针对AAA-TSM SAP调用AAA-TSM接口原语。
The AAA-TSM service layer interface primitives can be broadly characterized as follows:
AAA-TSM服务层接口原语可以大致描述如下：
- Register a presentation end point address identifier and its associated set of attributes to a service access point.
- 将表示端点地址标识符及其关联属性集注册到服务访问点。
- Send a presentation layer message to a specified destination presentation layer peer end point address.
- 将表示层消息发送到指定的目标表示层对等端点地址。
- Receive a presentation layer message from another presentation layer end point address. A receive operation may select a specific originating presentation layer end point address from which the message is expected, or receive a message from any presentation layer peer.
- 从另一个表示层端点地址接收表示层消息。接收操作可以选择消息预期来自的特定原始表示层端点地址，或者从任何表示层对等方接收消息。
- The AAA-TSM service layer calls an application specific authorization decision function, which returns a condition code expressing an approval, denial, or partially approves with a referral to another AAA Server.
- AAA-TSM服务层调用一个特定于应用程序的授权决策函数，该函数返回一个条件代码，表示批准、拒绝或部分批准，并引用另一个AAA服务器。
- AAA-TSM service layer tells the presentation layer to commit an earlier partially approved authorization request.
- AAA-TSM服务层告诉表示层提交先前部分批准的授权请求。
- Cancel an earlier partially approved authorization request (i.e. rollback).
- 取消先前部分批准的授权请求（即回滚）。
- The presentation service layer notifies the AAA-TSM service layer that it has terminated an in-progress Authorized Session.
- 表示服务层通知AAA-TSM服务层它已终止正在进行的授权会话。
- AAA-TSM service layer notifies the presentation service layer that another presentation service layer peer has terminated an Authorized Session.
- AAA-TSM服务层通知表示服务层另一个表示服务层对等方已终止授权会话。
- Un-register a presentation service layer end point address.
- 取消注册表示服务层端点地址。
The AAA-TSM service layer end point name space is the N-tuple formed by concatenating the following components:
AAA-TSM服务层端点名称空间是通过连接以下组件形成的N元组：
- AAA Server's Reliable/Secure Transport layer end point address
- AAA服务器的可靠/安全传输层端点地址
- AAA-TSM authorization request serial number, a unique durable unsigned integer generated by the AAA Server who first receives the User's authorization request.
- AAA-TSM授权请求序列号，是由首先接收用户授权请求的AAA服务器生成的唯一持久无符号整数。
Some AAA applications may require that each assigned AAA-TSM transaction serial number be stored in persistent storage, and require that it be recoverable across AAA Server system re-boots. The serial number generation algorithm must be guaranteed unique even if the AAA Server does a re-boot.
一些AAA应用程序可能要求将每个分配的AAA-TSM事务序列号存储在永久性存储器中，并要求它可以在AAA服务器系统重新引导时恢复。即使AAA服务器重新启动，序列号生成算法也必须保证唯一。
The layering paradigm makes it possible to use the most appropriate syntax for each application for encoding the Application Specific Information units of that application. This encoding would take place at the presentation layer. Similarly the application layer can recognize the semantics specific to each application. Figure 6 illustrates some possible AAA protocol stacks.
分层范例使得为每个应用程序使用最合适的语法来编码该应用程序的特定于应用程序的信息单元成为可能。这种编码将在表示层进行。类似地，应用层可以识别特定于每个应用程序的语义。图6说明了一些可能的AAA协议栈。
+------------++------------++-----------++-----------++----------+
| || Application|| E-Commerce|| Bandwidth || Roaming &|
| AAA || specific || Internet || Broker || mobile IP|
| Application||object class|| Open ||cross-admin|| remote |
| Service || interface || Trading || domain || access |
| Layer ||specified in|| Protocol || COPS || AVP |
| || CORBA IDL || (IOTP) || extensions|| lexicons |
+------------++------------++-----------++-----------++----------+
| || CORBA ||Extensible || Common || DIAMETER |
|Presentation|| Generic || Markup || Open || or |
| Service || Inter-ORB || Language || Policy || RADIUS |
| Layer || Protocol || (XML) ||Specificatn||Attribute |
| || (GIOP) || || (COPS) ||Value/Pair|
+------------++------------++-----------++-----------++----------+
| AAA-TSM Service Layer Application Program Interface (API) |
+----------------------------------------------------------------+
| AAA Transaction/Session Management (AAA-TSM) Service Layer |
+----------------------------------------------------------------+
| Reliable Secure Transport Layer |
+----------------------------------------------------------------+
+------------++------------++-----------++-----------++----------+
| || Application|| E-Commerce|| Bandwidth || Roaming &|
| AAA || specific || Internet || Broker || mobile IP|
| Application||object class|| Open ||cross-admin|| remote |
| Service || interface || Trading || domain || access |
| Layer ||specified in|| Protocol || COPS || AVP |
| || CORBA IDL || (IOTP) || extensions|| lexicons |
+------------++------------++-----------++-----------++----------+
| || CORBA ||Extensible || Common || DIAMETER |
|Presentation|| Generic || Markup || Open || or |
| Service || Inter-ORB || Language || Policy || RADIUS |
| Layer || Protocol || (XML) ||Specificatn||Attribute |
| || (GIOP) || || (COPS) ||Value/Pair|
+------------++------------++-----------++-----------++----------+
| AAA-TSM Service Layer Application Program Interface (API) |
+----------------------------------------------------------------+
| AAA Transaction/Session Management (AAA-TSM) Service Layer |
+----------------------------------------------------------------+
| Reliable Secure Transport Layer |
+----------------------------------------------------------------+
Fig. 6 -- Possible AAA Protocol Stacks
图6——可能的AAA协议栈
Security considerations for the framework on which the work described in this memo is based are discussed in [2]. Security requirements for authorization are listed in section 2.2 of [3].
[2]中讨论了本备忘录中所述工作所基于的框架的安全注意事项。[3]第2.2节列出了授权的安全要求。
This memo identifies a basic set of AAA functions that are general in nature and common to many different AAA applications. We propose that a standard set of security mechanisms should be defined as part of a base AAA protocol which would include such things as public key encryption and digital signatures that could be applied to individual information units within an AAA message. Security with this granularity is needed to meet the end-to-end security requirement specified in section 2.2.7 of [3] because a single AAA message may
本备忘录确定了一组基本的AAA功能，这些功能在本质上是通用的，对于许多不同的AAA应用程序来说是通用的。我们建议，应将一组标准的安全机制定义为基本AAA协议的一部分，该协议将包括公钥加密和数字签名等内容，这些内容可应用于AAA消息中的单个信息单元。这种粒度的安全性需要满足[3]第2.2.7节中规定的端到端安全要求，因为单个AAA消息可能
contain multiple information units each generated by AAA servers from different administrative domains and destined to AAA servers in different domains.
包含多个信息单元，每个信息单元由来自不同管理域的AAA服务器生成，并发送到不同域中的AAA服务器。
In addition, it may be necessary to encrypt or sign an entire AAA message on a hop-by-hop basis. This could be handled by a standard, lower layer protocol such as IPSEC. If so, then certain auditing requirements will have to be met so that it can be established later that the messages relative to some specific session ID were, in fact, protected in a particular way. Alternatively, hop-by-hop security mechanisms may be built into the base AAA protocol itself.
此外，可能需要逐跳对整个AAA消息进行加密或签名。这可以通过标准的低层协议（如IPSEC）来处理。如果是这样，则必须满足某些审核要求，以便以后可以确定与某些特定会话ID相关的消息实际上是以特定方式受到保护的。或者，可以将逐跳安全机制构建到基本AAA协议本身中。
Glossary
术语汇编
Application Specific Information (ASI) -- information in an AAA protocol message that is specific to a particular application.
应用程序特定信息（ASI）——AAA协议消息中特定于特定应用程序的信息。
Application Specific Module (ASM) -- a software module that implements a program interface to a generic AAA server which handles application specific functionality for an AAA protocol message.
特定于应用程序的模块（ASM）——一个软件模块，实现通用AAA服务器的程序接口，该服务器处理AAA协议消息的特定于应用程序的功能。
Service Provider -- an organization which provides a service.
服务提供者——提供服务的组织。
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, D., 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，D.，Holdrege，M.和D.Spence，“AAA授权框架”，RFC 29042000年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] 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.
[4] 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月。
[5] Blaze, M., Feigenbaum, J., Ioannidis, J. and A. Keromytis, "The KeyNote Trust-Management System Version 2", RFC 2704, September 1999.
[5] Blaze，M.，Feigenbaum，J.，Ioannidis，J.和A.Keromytis，“KeyNote信托管理系统版本2”，RFC 2704，1999年9月。
Authors' Addresses
作者地址
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
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
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
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
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编辑功能的资金目前由互联网协会提供。