Network Working Group S. Farrell
Request for Comments: 2906 Baltimore Technologies
Category: Informational J. Vollbrecht
Interlink Networks, Inc.
P. Calhoun
Sun Microsystems, Inc.
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 S. Farrell
Request for Comments: 2906 Baltimore Technologies
Category: Informational J. Vollbrecht
Interlink Networks, Inc.
P. Calhoun
Sun Microsystems, Inc.
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 Requirements
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 document specifies the requirements that Authentication Authorization Accounting (AAA) protocols must meet in order to support authorization services in the Internet. The requirements have been elicited from a study of a range of applications including mobile-IP, roamops and others.
本文档规定了认证授权记帐（AAA）协议必须满足的要求，以支持Internet中的授权服务。这些要求是从一系列应用的研究中得出的，包括移动IP、ROAMOP和其他应用。
Table Of Contents
目录
1. Introduction.................................................2
2. Requirements.................................................3
2.1 Authorization Information..............................3
2.2 Security of authorization information..................7
2.3 Time...................................................9
2.4 Topology..............................................10
2.5 Application Proxying..................................12
2.6 Trust Model...........................................12
2.7 Not just transactions.................................14
2.8 Administration........................................15
2.9 Bytes on-the-wire.....................................16
2.10 Interfaces............................................17
2.11 Negotiation...........................................18
3. Security Considerations.....................................19
4. References..................................................20
Authors' Addresses.............................................20
Full Copyright Statement.......................................23
1. Introduction.................................................2
2. Requirements.................................................3
2.1 Authorization Information..............................3
2.2 Security of authorization information..................7
2.3 Time...................................................9
2.4 Topology..............................................10
2.5 Application Proxying..................................12
2.6 Trust Model...........................................12
2.7 Not just transactions.................................14
2.8 Administration........................................15
2.9 Bytes on-the-wire.....................................16
2.10 Interfaces............................................17
2.11 Negotiation...........................................18
3. Security Considerations.....................................19
4. References..................................................20
Authors' Addresses.............................................20
Full Copyright Statement.......................................23
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 [FRMW] AAA Authorization Requirements (this document) AAA Authorization Application Examples [SAMP]
AAA授权框架[FRMW]AAA授权要求（本文件）AAA授权应用示例[SAMP]
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小组和该领域的其他工作人员可以使用该工作，而不是作为架构或需求的最终描述。
The process followed in producing this document was to analyze the requirements from [SAMP] based on a common understanding of the AAA authorization framework [FRMW]. This document assumes familiarity with both the general issues involved in authorization and, in particular, the reader will benefit from a reading of [FRMW] where, for example, definitions of terms can be found.
编制本文件的过程是基于对AAA授权框架[FRMW]的共同理解，分析[SAMP]的需求。本文件假设读者熟悉授权涉及的一般问题，尤其是读者将从阅读[FRMW]中获益，例如，可以找到术语定义。
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“要求”、“应该”、“建议”和“可能”应按照[RFC2119]中的说明进行解释。
Requirements are grouped under headings for convenience; this grouping is not significant.
为方便起见，将需求分组在标题下；这一分组并不重要。
Definitions and explanations of some of the technical terms used in this document may be found in [FRMW].
本文件中使用的一些技术术语的定义和解释见[FRMW]。
Each requirement is presented as a succinct (usually a sentence or two) statement. Most are followed by a paragraph of explanatory material, which sometimes contains an example. Fully described examples may be found in [SAMP].
每个需求都以简洁（通常是一两句）的形式呈现。大多数后面都有一段解释性材料，其中有时包含一个示例。在[SAMP]中可以找到完整描述的示例。
The requirements presented are not intended to be "orthogonal", that is, some of them repeat, or overlap, with others.
所提出的要求并非旨在“正交”，即其中一些要求与其他要求重复或重叠。
2.1.1 Authorization decisions MUST be able to be based on information about the requestor, the service/method requested, and the operating environment (authorization information). AAA protocols are required to transport this information.
2.1.1 授权决策必须能够基于关于请求者、请求的服务/方法以及操作环境（授权信息）的信息。需要AAA协议来传输此信息。
This simply states the requirement for a protocol and an access decision function, which takes inputs, based on the requestor, the resource requested and the environment.
这只是说明了对协议和访问决策函数的需求，该函数根据请求者、请求的资源和环境进行输入。
2.1.2 It MUST be possible to represent authorization information as sets of attributes. It MAY be possible to represent authorization information as objects.
2.1.2 必须能够将授权信息表示为属性集。可以将授权信息表示为对象。
This states that authorization information must be decomposable into sets of attributes. It is not intended to imply any particular mechanism for representing attributes.
这表明授权信息必须可分解为属性集。它并不意味着表示属性的任何特定机制。
2.1.3 It MUST be possible to package authorization information so that the authorization information for multiple services or applications can be carried in a single message in a AAA or application protocol.
2.1.3 必须能够打包授权信息，以便在AAA或应用程序协议中的单个消息中携带多个服务或应用程序的授权信息。
This states that a protocol, which always required separate AAA messages/transactions for each service/application, would not meet the requirement. For example, it should be possible for a single AAA message/transaction to be sufficient to allow both network and application access.
这表明，对于每个服务/应用程序，始终需要单独的AAA消息/事务的协议将不符合要求。例如，单个AAA消息/事务应足以允许网络和应用程序访问。
2.1.4 Standard attributes types SHOULD be defined which are relevant to many Internet applications/services (e.g. identity information, group information, ...)
2.1.4 应定义与许多互联网应用程序/服务相关的标准属性类型（例如身份信息、组信息等）
There are many attributes that are used in lots of contexts, and these should only be defined once, in order to promote interoperability and prevent duplication of effort.
有许多属性在许多上下文中使用，这些属性只应定义一次，以促进互操作性并防止重复工作。
2.1.5 Authorization decisions MUST NOT be limited to being based on identity information, i.e. AAA protocols MUST support the use of non-identifying information, e.g. to support role based access control (RBAC).
2.1.5 授权决策不得限于基于身份信息，即AAA协议必须支持使用非身份信息，例如支持基于角色的访问控制（RBAC）。
Authorization based on clearances, roles, groups or other information is required to be supported. A AAA protocol that only carried identity information would not meet the requirement.
需要支持基于许可、角色、组或其他信息的授权。仅携带身份信息的AAA协议不符合要求。
2.1.6 Authorization data MAY include limits in addition to attributes which are directly "owned" by end entities.
2.1.6 授权数据可能包括终端实体直接“拥有”的属性之外的限制。
This states that some attributes do not simply represent attributes of an entity, for example a spending limit of IR 1,000 is not an intrinsic attribute of an entity. This also impacts on the access decision function, in that the comparison to be made is not a simple equality match.
这表明某些属性并不简单地表示实体的属性，例如，IR 1000的支出限额不是实体的固有属性。这也会影响访问决策功能，因为要进行的比较不是简单的相等匹配。
2.1.7 It MUST be possible for other (non-AAA) protocols to define their own attribute types, which can then be carried within an authorization package in a AAA or application protocol.
2.1.7 其他（非AAA）协议必须能够定义自己的属性类型，然后可以在AAA或应用程序协议的授权包中携带这些属性类型。
This states that the attributes that are significant in an authorization decision, may be application protocol dependent. For example, many attribute types are defined by [RFC2138] and support for the semantics of these attributes will be required. Of course, only AAA entities that are aware of the added attribute types can make use of them.
这表明在授权决策中重要的属性可能依赖于应用程序协议。例如，许多属性类型由[RFC2138]定义，需要对这些属性的语义提供支持。当然，只有知道添加的属性类型的AAA实体才能使用它们。
2.1.8 It SHOULD be possible for administrators of deployed systems to define their own attribute types, which can then be carried within an authorization package in a AAA or application protocol.
2.1.8 已部署系统的管理员应该可以定义自己的属性类型，然后可以在AAA或应用程序协议的授权包中携带这些属性类型。
This states that the attributes that are significant in an authorization decision, may be dependent on a closed environment. For example, many organizations have a well-defined scheme of seniority, which can be used to determine access levels. Of course, only AAA entities that are aware of the added attribute types can make use of them.
这表明在授权决策中重要的属性可能依赖于封闭环境。例如，许多组织都有一个定义良好的资历方案，可用于确定访问级别。当然，只有知道添加的属性类型的AAA实体才能使用它们。
2.1.9 It SHOULD be possible to define new attribute types without central administration and control of attribute name space.
2.1.9 在没有集中管理和控制属性名称空间的情况下，应该可以定义新的属性类型。
A centralized or distributed registration scheme of some sort is needed if collisions in attribute type allocations are to be avoided. However a AAA protocol which always requires use of such a centralized registration would not meet the requirement. Of course, collisions should be avoided where possible.
如果要避免属性类型分配中的冲突，则需要某种集中或分布式注册方案。然而，始终需要使用这种集中注册的AAA协议将不符合要求。当然，应尽可能避免碰撞。
2.1.10 It MUST be possible to define attribute types so that an instance of an attribute in a single AAA message can have multiple values.
2.1.10 必须能够定义属性类型，以便单个AAA消息中的属性实例可以具有多个值。
This states that a protocol which does not allow multiple instances of an attribute in a message/transaction would not meet the requirement. For example it should be possible to have a "group" attribute which contains more than one groupname (or number or whatever).
这表明，不允许在消息/事务中有多个属性实例的协议将不符合要求。例如，应该可以有一个包含多个groupname（或number或其他）的“group”属性。
2.1.11 If MUST be possible to distinguish different instances of the same authorization attribute type or value, on the basis of "security domain" or "authority".
2.1.11 必须能够根据“安全域”或“权限”区分相同授权属性类型或值的不同实例。
This recognizes that it is important to be able to distinguish between attributes based not only on their value. For example, all NT domains (which use the English language) have an Administrators group, an access decision function has to be able to determine to which of these groups the requestor belongs.
这就认识到，重要的是能够区分属性，而不仅仅是基于它们的值。例如，所有NT域（使用英语）都有一个Administrators组，访问决策功能必须能够确定请求者所属的组。
2.1.12 AAA protocols MUST specify mechanisms for updating the rules which will be used to control authorization decisions.
2.1.12 AAA协议必须指定更新用于控制授权决策的规则的机制。
This states that a AAA protocol that cannot provide a mechanism for distributing authorization rules is not sufficient. For example, this could be used to download ACLs to a PDP.
这表明，不能提供分发授权规则机制的AAA协议是不够的。例如，这可用于将ACL下载到PDP。
Note that this is not meant to mean that this AAA protocol mechanism must always be used, simply that it must be available for use. In particular, storing authorization rules in a trusted repository (in many cases an LDAP server) will in many cases be used instead of such a AAA protocol mechanism. Neither does this requirement call for a standardized format for authorization rules, merely that there be a mechanism for transporting these.
请注意，这并不意味着必须始终使用此AAA协议机制，只意味着它必须可用。特别是，在许多情况下，将使用在可信存储库（在许多情况下是LDAP服务器）中存储授权规则来代替这种AAA协议机制。这一要求也不要求授权规则的标准化格式，只要求有一种传输这些规则的机制。
2.1.13 The AAA protocol MUST allow for chains of AAA entities to be involved in an authorization decision.
2.1.13 AAA协议必须允许AAA实体链参与授权决策。
This states that more than one AAA server may have to be involved in a single authorization decision. This may occur either due to a decision being spread across more than one "domain" or in order to distribute authorization within a single "domain".
这表明一个授权决策可能需要涉及多个AAA服务器。这可能是由于决策分布在多个“域”中，或者是为了在单个“域”中分发授权。
2.1.14 The AAA protocol MUST allow for intermediate AAA entities to add their own local authorization information to a AAA request or response.
2.1.14 AAA协议必须允许中间AAA实体将其自己的本地授权信息添加到AAA请求或响应中。
This states that where more than one AAA entity is involved in an authorization decision each of the AAA entities may manipulate the AAA messages involved either by adding more information or by processing parts of the information.
这表明，在授权决策涉及多个AAA实体的情况下，每个AAA实体可以通过添加更多信息或处理部分信息来操纵涉及的AAA消息。
2.1.15 AAA entities MAY be either be deployed independently or integrated with application entities.
2.1.15 AAA实体可以独立部署，也可以与应用程序实体集成。
This states that the AAA entities may either be implemented as AAA servers or integrated with application entities.
这表明AAA实体可以实现为AAA服务器或与应用实体集成。
2.1.16 The AAA protocol MUST support the creation and encoding of rules that are to be active inside one AAA server based on attributes published by another AAA server. The level of authorization of the requesting AAA Server MAY govern the view on attributes.
2.1.16 AAA协议必须支持根据另一台AAA服务器发布的属性创建和编码在一台AAA服务器内活动的规则。请求AAA服务器的授权级别可以控制属性视图。
This states that one AAA entity may have to distribute authorization rules to another, and that the AAA entity that receives the rules may only be seeing part of the story.
这表明一个AAA实体可能必须将授权规则分发给另一个，并且接收规则的AAA实体可能只看到了部分情况。
2.1.17 AAA protocols MAY have to support the idea of critical and non-critical attribute types.
2.1.17 AAA协议可能必须支持关键和非关键属性类型的概念。
This is analogous to the use of the criticality flag in public key certificate extensions.
这类似于在公钥证书扩展中使用临界标志。
2.1.18 A AAA protocol MUST allow authorization rules to be expressed in terms of combinations of other authorization rules which have been evaluated.
2.1.18 AAA协议必须允许使用已评估的其他授权规则的组合来表示授权规则。
For example, access may only be granted if the requestor is member of the backup users group and not a member of the administrator's group. Note that this requirement does not state which types of combinations are to be supported.
例如，只有当请求者是备份用户组的成员而不是管理员组的成员时，才能授予访问权限。请注意，本要求未说明支持哪种类型的组合。
2.1.19 It SHOULD be possible to make authorization decisions based on the geographic location of a requestor, service or AAA entity.
2.1.19 应该能够根据请求者、服务或AAA实体的地理位置做出授权决策。
This is just an example of an authorization attribute type, notable because it requires different underlying implementation mechanisms.
这只是授权属性类型的一个示例，值得注意，因为它需要不同的底层实现机制。
2.1.20 It SHOULD be possible to make authorization decisions based on the identity or the equipment used by a requestor, service or AAA entity.
2.1.20 应该能够根据请求者、服务或AAA实体使用的身份或设备做出授权决策。
This is just an example of an authorization attribute type, notable because it may require different underlying implementation mechanisms (if IPSec isn't available).
这只是授权属性类型的一个示例，值得注意，因为它可能需要不同的底层实现机制（如果IPSec不可用）。
2.1.21 When there are multiple instances of a given attribute, there must be an unambiguous mechanism by which a receiving peer can determine the value of specified instance.
2.1.21 当给定属性有多个实例时，必须有一个明确的机制，通过该机制，接收对等方可以确定指定实例的值。
2.2.1 It MUST be possible for authorization information to be communicated securely in AAA and application protocols. Mechanisms that preserve authenticity, integrity and privacy for this information MUST be specified.
2.2.1 授权信息必须能够在AAA和应用程序协议中安全通信。必须指定保护此信息真实性、完整性和隐私的机制。
This states that there must be a well-defined method for securing authorization information, not that such methods must always be used. Whether support for these mechanisms is to be required for conformance is left open. In particular, mechanisms must be provided so that a service administrator in the middle of a chain cannot read or change authorization information being sent between other AAA entities.
这说明必须有一种定义良好的方法来保护授权信息，而不是必须始终使用这种方法。合规性是否需要对这些机制的支持仍然是未知数。特别地，必须提供机制，使得链中间的服务管理员不能读取或更改在其他AAA实体之间发送的授权信息。
2.2.2 AAA protocols MUST allow for use of an appropriate level of security for authorization information. AAA protocols MUST be able to support both highly secure and less secure mechanisms for data integrity/confidentiality etc.
2.2.2 AAA协议必须允许对授权信息使用适当级别的安全性。AAA协议必须能够支持高度安全和不太安全的数据完整性/机密性机制等。
It is important that AAA protocols do not mandate too heavy a security overhead, thus the security mechanisms specified don't always need to be used (though not using them may affect the authorization decision).
重要的是，AAA协议不要求过大的安全开销，因此不需要总是使用指定的安全机制（尽管不使用它们可能会影响授权决策）。
2.2.3 The security requirements MAY differ between different parts of a package of authorization information.
2.2.3 授权信息包的不同部分的安全要求可能不同。
Some parts may require confidentiality and integrity, some may only require integrity. This effectively states that we require something
有些零件可能需要保密性和完整性，有些零件可能只需要完整性。这实际上表明我们需要一些东西
like selective field security mechanisms. For example, information required to gain access to a network may have to be in clear, whilst information required for access to an application within that network may have to be encrypted in the AAA protocol.
比如选择性的现场安全机制。例如，访问网络所需的信息可能必须清晰，而访问该网络内的应用程序所需的信息可能必须在AAA协议中加密。
2.2.4 AAA protocols MUST provide mechanisms that prevent intermediate administrators breaching security.
2.2.4 AAA协议必须提供防止中间管理员破坏安全性的机制。
This is a basic requirement to prevent man-in-the-middle attacks, for example where an intermediate administrator changes AAA messages on the fly.
这是防止中间人攻击的基本要求，例如中间管理员动态更改AAA消息。
2.2.5 AAA protocols MUST NOT open up replay attacks based on replay of the authorization information.
2.2.5 AAA协议不得基于授权信息的重播而发起重播攻击。
For example, a AAA protocol should not allow flooding attacks where the attacker replays AAA messages that require the recipient to use a lot of CPU or communications before the replay is detected.
例如，AAA协议不应允许洪水攻击，即攻击者重播AAA消息，而在检测到重播之前，收件人需要使用大量CPU或通信。
2.2.6 AAA protocols MUST be capable of leveraging any underlying peer entity authentication mechanisms that may have been applied - this MAY provide additional assurance that the owner of the authorization information is the same as the authenticated entity. For example, if IPSec provides sufficient authentication, then it must be possible to omit AAA protocol authentication.
2.2.6 AAA协议必须能够利用可能已应用的任何底层对等实体身份验证机制-这可以提供授权信息所有者与已认证实体相同的额外保证。例如，如果IPSec提供了足够的身份验证，则必须可以省略AAA协议身份验证。
2.2.7 End-to-end confidentiality, integrity, peer-entity-authentication, or non-repudiation MAY be required for packages of authorization information.
2.2.7 授权信息包可能需要端到端的保密性、完整性、对等实体身份验证或不可否认性。
This states that confidentiality, (resp. the other security services), may have to be provided for parts of a AAA message, even where it is transmitted via other AAA entities. It does allow that such a AAA message may also contain non-confidential, resp. the other security services), parts. In addition, intermediate AAA entities may themselves be considered end-points for end-to-end security services applied to other parts of the AAA message.
这表明，即使AAA消息是通过其他AAA实体传输的，也可能必须为AAA消息的某些部分提供保密性（以及其他安全服务）。它确实允许此类AAA消息也可能包含非机密信息，即。其他安全服务）的零件。此外，中间AAA实体本身可被视为应用于AAA消息的其他部分的端到端安全服务的端点。
2.2.8 AAA protocols MUST be usable even in environments where no peer entity authentication is required (e.g. a network address on a secure LAN may be enough to decide).
2.2.8 即使在不需要对等实体身份验证的环境中（例如，安全LAN上的网络地址可能足以决定），AAA协议也必须可用。
This requirement (in a sense the opposite of 2.2.6), indicates the level of flexibility that is required in order to make the AAA protocol useful across a broad range of applications/services.
该要求（在某种意义上与2.2.6相反）表明了使AAA协议在广泛的应用程序/服务中有用所需的灵活性水平。
2.2.9 AAA protocols MUST specify "secure" defaults for all protocol options. Implementations of AAA entities MUST use these "secure" defaults unless otherwise configured/administered.
2.2.9 AAA协议必须为所有协议选项指定“安全”默认值。AAA实体的实现必须使用这些“安全”默认值，除非另有配置/管理。
This states that the out-of-the-box configuration must be "secure", for example, authorization decisions should result in denial of access until a AAA entity is configured. Note that the interpretation of "secure" will vary on a case-by-case basis, though the principle remains the same.
这表明开箱即用配置必须是“安全的”，例如，授权决策应导致拒绝访问，直到配置AAA实体。请注意，“安全”的解释将根据具体情况而有所不同，尽管原则保持不变。
2.3.1 Authorization information MUST be timely, which means that it MUST expire and in some cases MAY be revoked before expiry.
2.3.1 授权信息必须及时，这意味着它必须过期，在某些情况下可能在过期之前被撤销。
This states that authorization information itself is never to be considered valid for all time, every piece of authorization information must have associated either an explicit or implicit validity period or time-to-live.
这表明授权信息本身永远不会被视为始终有效，每一条授权信息都必须关联一个显式或隐式的有效期或生存时间。
2.3.2 AAA protocols MUST provide mechanisms for revoking authorization information, in particular privileges.
2.3.2 AAA协议必须提供撤销授权信息（特别是特权）的机制。
Where the validity or time-to-live is long, it may be necessary to revoke the authorization information, e.g. where someone leaves a company. Note that this requirement does not mandate a particular scheme for revocation, so that it is not a requirement for blacklists or CRLs.
如果有效期或有效期较长，则可能需要撤销授权信息，例如某人离开公司时。请注意，此要求并不强制要求撤销特定方案，因此它不是黑名单或CRL的要求。
2.3.3 A set of attributes MAY have an associated validity period - such that that the set MUST only be used for authorization decisions during that period. The validity period may be relatively long, (e.g. months) or short (hours, minutes).
2.3.3 一组属性可能有一个相关的有效期，因此该组属性只能用于该期间的授权决策。有效期可能相对较长（如月）或较短（小时、分钟）。
This states that explicit validity periods are, in some cases, needed at the field level.
这表明，在某些情况下，在实地一级需要明确的有效期。
2.3.4 Authorization decisions MAY be time sensitive. Support for e.g. "working hours" or equivalent MUST be possible.
2.3.4 授权决策可能对时间敏感。必须提供支持，例如“工作时间”或同等服务。
This states that the AAA protocol must be able to support the transmission of time control attributes, although it does not mandate that AAA protocols must include a standard way of expressing the "working hours" type constraint.
这表明AAA协议必须能够支持时间控制属性的传输，尽管它并不要求AAA协议必须包括表示“工作时间”类型约束的标准方式。
2.3.5 It MUST be possible to support authorization decisions that produce time dependent results.
2.3.5 必须能够支持产生时间相关结果的授权决策。
For example, an authorization result may be that service should be provided for a certain period. In such cases a AAA protocol must be able to transport this information, possibly as a specific result of the authorization decision, or, as an additional "termination of service" AAA message transmitted later.
例如，授权结果可能是服务应该提供一段时间。在这种情况下，AAA协议必须能够传输该信息，可能是由于授权决定的特定结果，或者是作为稍后传输的附加“服务终止”AAA消息。
2.3.6 It MUST be possible to support models where the authorization information is issued in well in advance of an authorization decision rather than near the time of the authorization decision.
2.3.6 必须能够支持授权信息在授权决策之前发布而不是在授权决策之前发布的模型。
This is required in order to support pre-paid (as opposed to subscription) scenarios (e.g. for VoIP).
这是为了支持预付费（而不是订阅）场景（例如VoIP）所必需的。
2.3.7 It SHOULD be possible to support models where the authorization decision is made in advance of a service request.
2.3.7 应该能够支持在服务请求之前做出授权决策的模型。
This is for some applications such as backup, where actions are scheduled for future dates. It also covers applications that require reservation of resources.
这适用于某些应用程序，如备份，这些应用程序的操作计划在将来的日期执行。它还包括需要保留资源的应用程序。
2.3.8 A AAA mechanism must allow time stamp information to be carried along with authorization information (e.g. for non-repudiation).
2.3.8 AAA机制必须允许时间戳信息与授权信息一起携带（例如，用于不可否认性）。
The PKIX WG is developing a time stamp protocol, which can be used as part of a non-repudiation solution. In some environments it may be necessary that certain AAA protocol messages are timestamped (by a trusted authority) and that the timestamps are forwarded within subsequent AAA messages.
PKIX工作组正在开发一个时间戳协议，该协议可作为不可否认性解决方案的一部分使用。在某些环境中，可能需要（由可信机构）对某些AAA协议消息加上时间戳，并在后续AAA消息中转发时间戳。
2.4.1 AAA protocols MUST be able to support the use of the push, pull and agent models.
2.4.1 AAA协议必须能够支持推、拉和代理模型的使用。
This states that a protocol that only supported one model, say pull, would not meet the requirements of all the applications. The models are defined in [FRMW].
这表明，仅支持一种模型（如pull）的协议将无法满足所有应用程序的要求。模型定义见[FRMW]。
2.4.2 In transactions/sessions, which involve more than one AAA entity, each "hop" MAY use a different push/pull/agent model.
2.4.2 在涉及多个AAA实体的事务/会话中，每个“跃点”可以使用不同的推/拉/代理模型。
For example, in the mobile IP case, a "foreign" AAA server might pull authorization information from a broker, whereas the broker might push some authorization information to a "home" AAA server.
例如，在移动IP情况下，“外来”AAA服务器可能会从代理中提取授权信息，而代理可能会将一些授权信息推送到“本地”AAA服务器。
2.4.3 AAA Protocols MUST cater for applications and services where the entities involved in the application or AAA protocols belong to different (security) domains.
2.4.3 AAA协议必须适用于应用程序或AAA协议中涉及的实体属于不同（安全）域的应用程序和服务。
This states that it must be possible for any AAA protocol message to cross security or administrative domain boundaries. Typically, higher levels of security will be applied when crossing such boundaries, and accounting mechanisms may also have to be more stringent.
这表明任何AAA协议消息都必须能够跨越安全或管理域边界。通常，当跨越这些边界时，将采用更高级别的安全性，会计机制也可能必须更加严格。
2.4.4 AAA protocols MUST support roaming.
2.4.4 AAA协议必须支持漫游。
Roaming here may also be thought of as "away-from-home" operation. For example, this is a fundamental requirement for the mobile IP case.
在这里漫游也可能被认为是“离家出走”的操作。例如，这是移动IP案例的基本要求。
Dynamic mobility here means that a client moves from one domain to another, without having to completely re-establish e.g. whatever AAA session information is being maintained.
这里的动态移动意味着客户端从一个域移动到另一个域，而无需完全重新建立（例如，维护的AAA会话信息）。
2.4.6 An authorization decision MAY have to be made before the requestor has any other connection to a network.
2.4.6 在请求者与网络建立任何其他连接之前，可能必须做出授权决定。
For example, this means that the requestor can't go anywhere on the network to fetch anything and must do requests via an application/service or via an intermediate AAA entity. The AAA protocol should not overexpose such a server to denial-of-service attacks.
例如，这意味着请求者不能在网络上的任何地方获取任何东西，必须通过应用程序/服务或中间AAA实体执行请求。AAA协议不应使此类服务器过度暴露于拒绝服务攻击。
2.4.7 AAA protocols MUST support the use of intermediate AAA entities which take part in authorization transactions but which don't "own" any of the end entities or authorization data.
2.4.7 AAA协议必须支持使用中间AAA实体，这些实体参与授权事务，但不“拥有”任何终端实体或授权数据。
In some environments (e.g. roamops), these entities are termed brokers (though these are not the same as bandwidth brokers in the QoS environment).
在某些环境中（例如ROAMOP），这些实体被称为代理（尽管它们与QoS环境中的带宽代理不同）。
2.4.8 AAA protocols MAY support cases where an intermediate AAA entity returns a forwarding address to a requestor or AAA entity, in order that the requestor or originating AAA entity can contact another AAA entity.
2.4.8 AAA协议可以支持中间AAA实体向请求者或AAA实体返回转发地址的情况，以便请求者或发起AAA实体可以联系另一AAA实体。
This requirement recognizes that there will be routing issues with AAA servers, and that this requires that AAA protocols are able to help with such routing. For example, in the mobile IP case, a broker may be required, in part to allow the foreign and home AAA servers to get in contact.
这一要求认识到AAA服务器将存在路由问题，这要求AAA协议能够帮助进行此类路由。例如，在移动IP情况下，可能需要一个代理，部分是为了允许国外和国内AAA服务器联系。
2.4.9 It MUST be possible for an access decision function to discover the AAA server of a requestor. If the requestor provides information used in this discovery process then the access decision function MUST be able to verify this information in a trusted manner.
2.4.9 访问决策功能必须能够发现请求者的AAA服务器。如果请求者提供此发现过程中使用的信息，则访问决策功能必须能够以可信的方式验证此信息。
This states that not only do AAA servers have to be able to find one another, but that sometimes an application entity may have to find an appropriate AAA server.
这说明不仅AAA服务器必须能够找到彼此，而且有时应用程序实体可能必须找到合适的AAA服务器。
2.5.1 AAA protocols MUST support cases where applications use proxies, that is, an application entity (C), originates a service request to a peer (I) and this intermediary (I) also initiates a service request on behalf of the client (C) to a final target (T). AAA protocols MUST be such that the authorization decision made at T, MAY depend on the authorization information associated with C and/or with I. This "application proxying" must not introduce new security weaknesses in the AAA protocols. There MAY be chains of application proxies of any length.
2.5.1 AAA协议必须支持应用程序使用代理的情况，即应用程序实体（C）向对等方（I）发起服务请求，并且该中介体（I）还代表客户端（C）向最终目标（T）发起服务请求。AAA协议必须确保在T作出的授权决策可能取决于与C和/或I相关的授权信息。这种“应用程序代理”不得在AAA协议中引入新的安全弱点。可能存在任意长度的应用程序代理链。
Note that this requirement addresses application layer proxying - not chains of AAA servers. For example, a chain of HTTP proxies might each want to restrict the content they serve to the "outside". As the HTTP GET message goes from HTTP proxy to HTTP proxy, this requirement states that it must be possible that the authorization decisions made at each stage can depend on the user at the browser, and not say, solely on the previous HTTP proxy's identity. Of course there may only be a single AAA server involved, or there may be many.
请注意，此要求涉及应用程序层代理，而不是AAA服务器链。例如，一系列HTTP代理可能都希望将其服务的内容限制在“外部”。当HTTP GET消息从一个HTTP代理传递到另一个HTTP代理时，该要求指出，在每个阶段做出的授权决策必须可能取决于浏览器中的用户，而不仅仅是取决于先前HTTP代理的身份。当然，可能只涉及一个AAA服务器，也可能涉及多个。
2.5.2 Where there is a chain of application proxies, the AAA protocol flows at each stage MAY be independent, i.e. the first hop may use the push model, the second pull, the third the agent model.
2.5.2 在存在应用程序代理链的情况下，每个阶段的AAA协议流可以是独立的，即第一跳可以使用推送模型、第二拉送模型、第三跳和代理模型。
This simply restates a previous requirement (no. 2.4.7), to make it clear that this also applies when application proxying is being used.
这只是重申了先前的要求（第2.4.7条），以明确在使用应用程序代理时，这也适用。
2.6.1 AAA entities MUST be able to make decisions about which other AAA entities are trusted for which sorts of authorization information.
2.6.1 AAA实体必须能够决定哪些其他AAA实体可以信任哪些种类的授权信息。
This is analogous to a requirement in public key infrastructures: Just because someone can produce a cryptographically correct public key certificate does not mean that I should trust them for anything, in particular, I might trust the issuer for some purposes, but not for others.
这类似于公钥基础设施中的一个要求：仅仅因为某人可以生成加密正确的公钥证书，并不意味着我应该在任何事情上信任他们，特别是，我可能出于某些目的而信任颁发者，但不为其他目的。
2.6.2 AAA protocols MUST allow entities to be trusted for different purposes, trust MUST NOT be an all-or-nothing issue.
2.6.2 AAA协议必须允许为不同的目的信任实体，信任不能是全有或全无的问题。
This relates the packaging (no. 2.1.3) and trust (no. 2.6.1) requirements. For example, a AAA entity may trust some parts of an authorization package but not others.
这涉及包装（第2.1.3条）和信托（第2.6.1条）要求。例如，AAA实体可能信任授权包的某些部分，但不信任其他部分。
2.6.3 A confirmation of authorization MAY be required in order to initialize or resynchronize a AAA entity.
2.6.3 为了初始化或重新同步AAA实体，可能需要确认授权。
This states that a AAA entity may need to process some AAA protocol messages in order to initialize itself. In particular, a AAA entity may need to check that a previous AAA message remains "valid", e.g. at boot-time.
这表明AAA实体可能需要处理一些AAA协议消息以初始化自身。具体而言，AAA实体可能需要检查先前的AAA消息是否保持“有效”，例如在引导时。
2.6.4 A negation of static authorization MAY be required to shut down certain services.
2.6.4 关闭某些服务可能需要否定静态授权。
This is the converse of 2.6.5 above. It means that a AAA entity may be "told" by another that a previous AAA message is no longer "valid". See also 2.3.2 and 2.7.6.
这与上面的2.6.5相反。这意味着AAA实体可能会被另一个实体“告知”先前的AAA消息不再“有效”。另见2.3.2和2.7.6。
2.6.5 It MUST be possible to configure sets of AAA entities that belong to a local domain, so that they are mutually trusting, but so that any external trust MUST be via some nominated subset of AAA entities.
2.6.5 必须能够配置属于本地域的AAA实体集，以便它们相互信任，但任何外部信任都必须通过AAA实体的某些指定子集。
This states that for efficiency or organizational reasons, it must be possible to set up some AAA servers through which all "external" AAA services are handled. It also states that it must be possible to do this without over-burdening the "internal-only" AAA servers with onerous security mechanisms, just because some AAA servers do handle external relations.
这表明，出于效率或组织原因，必须能够设置一些AAA服务器，通过这些服务器处理所有“外部”AAA服务。它还指出，必须能够做到这一点，而不让“仅限内部”的AAA服务器承担繁重的安全机制负担，因为有些AAA服务器确实处理外部关系。
2.6.6 Intermediate AAA entities in a chain MUST be able to refuse a connection approved by an earlier entity in the chain.
2.6.6 链中的中间AAA实体必须能够拒绝链中较早实体批准的连接。
For example, in mobile IP the home network may authorize a connection, but the foreign network may refuse to allow the connection due to the settings chosen by the home network, say if the home network will refuse to pay.
例如，在移动IP中，家庭网络可以授权连接，但是由于家庭网络选择的设置，例如如果家庭网络将拒绝支付，则外部网络可以拒绝允许连接。
2.6.7 It SHOULD be possible to modify authorization for resources while a session is in progress without destroying other session information.
2.6.7 当会话正在进行时，应该可以修改资源的授权，而不会破坏其他会话信息。
For example, a "parent" AAA server should be able to modify the authorization state of sessions managed by a "child" AAA server, say by changing the maximum number of simultaneous sessions which are allowed.
例如，“父”AAA服务器应该能够修改“子”AAA服务器管理的会话的授权状态，例如通过更改允许的最大同时会话数。
2.7.1 Authorization decisions MAY be context sensitive, AAA protocols MUST enable such decisions.
2.7.1 授权决策可能是上下文敏感的，AAA协议必须支持此类决策。
This states that AAA protocols need to support cases where the authorization depends, (perhaps even only depends), on the current state of the system, e.g. only seven sessions allowed, seventh decision depends on existence of six current sessions. Since the context might involve more than one service, the AAA protocol is likely to have to offer some support.
这表明AAA协议需要支持授权取决于（甚至可能仅取决于）系统当前状态的情况，例如，仅允许七个会话，第七个决定取决于六个当前会话的存在。由于上下文可能涉及多个服务，AAA协议可能必须提供一些支持。
2.7.2 AAA protocols SHOULD support both the authorization of transactions and continuing authorization of sessions.
2.7.2 AAA协议应支持事务授权和会话持续授权。
This states that AAA entities may have to maintain state and act when the state indicates some condition has been met.
这表明AAA实体可能必须保持状态，并在状态表明满足某些条件时采取行动。
2.7.3 Within a single session or transaction, it MUST be possible to interleave authentication, authorization and accounting AAA messages.
2.7.3 在单个会话或事务中，必须能够交错身份验证、授权和记帐AAA消息。
This states, that e.g. a session may have to use initial authentication, authorization and accounting AAA message(s), but also have to include e.g. re-authentication every 30 minutes, or a continuous "drip-drip" of accounting AAA messages.
这表明，例如会话可能必须使用初始身份验证、授权和记帐AAA消息，但也必须包括例如每30分钟重新身份验证，或记帐AAA消息的连续“滴滴”。
2.7.4 Authorization decisions may result in a "not ready" answer.
2.7.4 授权决策可能会导致“未准备就绪”的回答。
This states that yes and no are not the only outcomes of an authorization decision. In particular, if the AAA entity cannot yet give a decision, it might have to return such a result. This is analogous to how public key certification requests are sometimes handled in PKI management protocols.
这表明是和否不是授权决策的唯一结果。特别是，如果AAA实体还不能给出决策，它可能必须返回这样的结果。这类似于PKI管理协议中有时处理公钥认证请求的方式。
2.7.5 A AAA entity MAY re-direct a AAA request that it has received.
2.7.5 AAA实体可以重新定向其已收到的AAA请求。
This states that if entity "a" asks "b", then "b" may say: "don't ask me, ask 'c'". This is analogous to HTTP re-direction (status code 307).
这表明，如果实体“a”问“b”，那么“b”可能会说：“不要问我，问‘c’”。这类似于HTTP重定向（状态代码307）。
2.7.6 AAA protocols SHOULD allow a AAA entity to "take back" an authorization.
2.7.6 AAA协议应允许AAA实体“收回”授权。
The expectation is that AAA protocols will support the ability of a AAA entity to signal an application or other AAA entity that an authorization (possibly previously granted by a third AAA entity) is no longer valid.
预期AAA协议将支持AAA实体向应用程序或其他AAA实体发出授权（可能以前由第三个AAA实体授予）不再有效的信号的能力。
2.8.1 It MUST be possible for authorization data to be administered on behalf of the end entities and AAA entities.
2.8.1 必须能够代表终端实体和AAA实体管理授权数据。
This requirement indicates that administration of AAA has to be considered as part of protocol design - a AAA protocol, which required all AAA entities act independent of all other AAA entities, would not meet the requirement.
该要求表明，AAA的管理必须被视为协议设计的一部分-要求所有AAA实体独立于所有其他AAA实体行事的AAA协议将不符合该要求。
2.8.2 Centralizable administration of all features SHOULD be supported.
2.8.2 应支持所有功能的集中管理。
It should be possible (if it meets the domain requirements) to centralize or distribute the administration of AAA.
应该可以（如果满足域要求）集中或分发AAA的管理。
2.8.3 AAA protocols SHOULD support cases where the user (as opposed to an administrator) authorizes a transaction.
2.8.3 AAA协议应该支持用户（而不是管理员）授权事务的情况。
For example, a user might want to control anti-spam measures or authorize things like a purchase. In such cases, the user is acting somewhat like an administrator.
例如，用户可能希望控制反垃圾邮件措施或授权购买等事项。在这种情况下，用户的行为有点像管理员。
2.8.4 One AAA entity MAY create authorization rules for another AAA entity.
2.8.4 一个AAA实体可以为另一个AAA实体创建授权规则。
This is required to properly support delegation of authority, however when allowed, this must be able to be done in a secure fashion.
这是正确支持授权所必需的，但是在允许的情况下，这必须能够以安全的方式完成。
2.8.5 AAA protocols SHOULD support failure recovery when one AAA entity in a chain of AAA entities that maintain state about a session fails.
2.8.5 当维护会话状态的AAA实体链中的一个AAA实体发生故障时，AAA协议应支持故障恢复。
For example, in a network access situation it may be required that a AAA server which has crashed be able to determine how many sessions are in progress, in order to make the "next" authorization decision.
例如，在网络访问情况下，可能需要崩溃的AAA服务器能够确定有多少会话正在进行，以便做出“下一个”授权决策。
2.8.6 It SHOULD be possible for a AAA entity to query the authorization state of another AAA entity.
2.8.6 AAA实体应该可以查询另一个AAA实体的授权状态。
This may be required as part of a failure recovery procedure.
这可能是故障恢复程序的一部分。
2.8.7 AAA protocols MUST be able to support "hot fail-over" for server components without loss of state information.
2.8.7 AAA协议必须能够在不丢失状态信息的情况下支持服务器组件的“热故障转移”。
This states that AAA protocols must be able to support cases where, when a server is no longer operable, a secondary server can automatically be brought "live" without losing important state information.
这说明AAA协议必须能够支持这样的情况：当服务器不再可操作时，辅助服务器可以自动“激活”，而不会丢失重要的状态信息。
2.9.1 Authorization separate from authentication SHOULD be allowed when necessary, but the AAA protocols MUST also allow for a single message to request both authentication and authorization.
2.9.1 必要时应允许独立于身份验证的授权，但AAA协议还必须允许单个消息同时请求身份验证和授权。
AAA protocols have to allow a split between authentication and authorization so that different mechanisms are used for each. This states that sometimes both types of information need to be carried in the same message.
AAA协议必须允许在身份验证和授权之间进行分割，以便为每一种协议使用不同的机制。这说明有时两种类型的信息需要在同一条消息中携带。
2.9.2 In order to minimize resource usage (e.g. reduce roundtrips) it MUST be possible to embed AAA PDUs into other protocols.
2.9.2 为了尽量减少资源使用（例如减少往返），必须能够将AAA PDU嵌入到其他协议中。
This states that the AAA protocol authorization packages must be defined so that they can also be carried in other protocols. For example, depending on AAA protocol header information in order to reference an authorization package could cause a protocol to fail to meet the requirement.
这说明必须定义AAA协议授权包，以便它们也可以在其他协议中携带。例如，根据AAA协议头信息来引用授权包可能会导致协议无法满足要求。
2.9.3 A AAA protocol MAY provide mechanisms for replication of state information.
2.9.3 AAA协议可以提供复制状态信息的机制。
This can be required e.g. to support resiliency in cases where hot fail-over is required. Note that AAA protocols are of course, subject to normal protocol design requirements to do with reliability, no single-point-of-failure etc even though these are not all specified here.
这可能是必需的，例如，在需要热故障转移的情况下支持恢复能力。请注意，AAA协议当然受制于正常的协议设计要求，包括可靠性、无单点故障等，尽管此处并未全部规定。
2.9.4 A AAA protocol SHOULD allow the possibility for implementation of a gateway function between the AAA protocol and other legacy AAA related protocols.
2.9.4 AAA协议应允许在AAA协议和其他传统AAA相关协议之间实现网关功能。
For example, some form of support for [RFC2138] as a legacy protocol is very likely to be required. Of course, the use of such a gateway is almost certain to mean not meeting some other requirements, (e.g. end-to-end security), for transactions routed through the gateway. There is no implication that such gateway functionality needs to be a separate server.
例如，很可能需要某种形式的对[RFC2138]作为遗留协议的支持。当然，使用这样的网关几乎肯定意味着不满足通过网关路由的事务的某些其他要求（例如端到端安全性）。这并不意味着这样的网关功能需要是一个单独的服务器。
2.9.5 A AAA protocol MUST be able to support use of a wide range of primitive data types, including RFC2277.
2.9.5 AAA协议必须能够支持多种基本数据类型的使用，包括RFC2277。
For example, various sized, signed and unsigned integers, possibly including multi-precision integers will almost certainly need to be transported. Floating point support according to ANSI IEEE 754-1985 may also be required.
例如，几乎肯定需要传输各种大小、有符号和无符号整数，可能包括多精度整数。也可能需要符合ANSI IEEE 754-1985的浮点支持。
2.9.6 A AAA protocol transport SHOULD support being optimized for a long-term exchange of small packets in a stream between a pair of hosts.
2.9.6 AAA协议传输应支持针对一对主机之间的流中小数据包的长期交换进行优化。
NASes typically have a high number of transactions/second, so the AAA protocol MUST allow the flow of requests to be controlled in order for the server to make efficient use of it's receive buffers.
NASE通常每秒有大量事务，因此AAA协议必须允许控制请求流，以便服务器有效利用其接收缓冲区。
2.9.7 A AAA protocol MUST provide support for load balancing.
2.9.7 AAA协议必须提供负载平衡支持。
In the event that a peer's cannot receive any immediate requests, the AAA protocol MUST allow for an implementation to balance the load of requests among a set of peers.
在对等方无法接收任何即时请求的情况下，AAA协议必须允许实现在一组对等方之间平衡请求负载。
2.10.1 It SHOULD be possible that authorization data can be used for application purposes.
2.10.1 授权数据应该可以用于应用目的。
For example, in web access, if the authorization data includes a group name, mechanisms to make this data available to the application so that it can modify the URL originally requested are desirable.
例如，在web访问中，如果授权数据包括组名，则需要使该数据可供应用程序使用的机制，以便应用程序可以修改最初请求的URL。
2.10.2 It SHOULD be possible that authorization data can be used to mediate the response to a request.
2.10.2 授权数据应该可以用于调解对请求的响应。
For example, with web access the clearance attribute value may affect the content of the HTTP response message.
例如，对于web访问，清除属性值可能会影响HTTP响应消息的内容。
2.10.3 AAA protocols SHOULD be able to operate in environments where requestors are not pre-registered (at least for authorization purposes, but possibly also for authentication purposes).
2.10.3 AAA协议应该能够在请求者未预先注册的环境中运行（至少出于授权目的，但也可能出于身份验证目的）。
This is necessary to be able to scale a AAA solution where there are many requestors.
这对于能够在有许多请求者的情况下扩展AAA解决方案是必要的。
2.10.4 AAA protocols MUST be able to support a linkage between authorization and accounting mechanisms.
2.10.4 AAA协议必须能够支持授权和记帐机制之间的链接。
Motherhood and apple-pie.
母性和苹果派。
2.10.5 AAA protocols MUST be able to support accountability (audit/non-repudiation) mechanisms.
2.10.5 AAA协议必须能够支持责任（审计/不可否认）机制。
Sometimes, an authorization decision will be made where the requestor has not authenticated. In such cases, it must be possible that the authorization data used is linked to audit or other accountability mechanisms. Note that this requirement does not call for mandatory support for digital signatures, or other parts of a non-repudiation solution.
有时，在请求者未进行身份验证的情况下，会做出授权决定。在这种情况下，所使用的授权数据必须有可能与审计或其他问责机制相关联。请注意，此要求不要求强制支持数字签名或不可否认性解决方案的其他部分。
2.11.1 AAA protocols MUST support the ability to refer to sets of authorization packages in order to allow peers negotiate a common set.
2.11.1 AAA协议必须支持引用授权包集的能力，以便允许对等方协商公共集。
Given that peers may support different combinations of authorization attribute types and packages, the requirement states that protocol support is required to ensure that the peers use packages supported by both peers.
鉴于对等方可能支持授权属性类型和包的不同组合，该需求说明需要协议支持，以确保对等方使用两个对等方支持的包。
2.11.2 It MUST be possible to negotiate authorization packages between AAA entities that are not in direct communication.
2.11.2 必须能够在不直接通信的AAA实体之间协商授权包。
This states that where, e.g. a broker is involved, the end AAA servers might still need to negotiate.
这表明，在涉及代理的情况下，终端AAA服务器可能仍需要协商。
2.11.3 Where negotiation fails to produce an acceptable common supported set then access MUST be denied.
2.11.3 如果协商无法生成可接受的公共支持集，则必须拒绝访问。
For example, a server cannot grant access if it cannot understand the attributes of the requestor.
例如，如果服务器无法理解请求者的属性，则无法授予访问权限。
2.11.4 Where negotiation fails to produce an acceptable common supported set then it SHOULD be possible to generate an error indication to be sent to another AAA entity.
2.11.4 如果协商无法生成可接受的公共支持集，则应该可以生成一个错误指示以发送给另一个AAA实体。
If negotiation fails, then some administrator intervention is often required, and protocol support for this should be provided.
如果协商失败，则通常需要一些管理员干预，并为此提供协议支持。
2.11.5 It MUST be possible to pre-provision the result of a negotiation, but in such cases, the AAA protocol MUST include a confirmation of the "negotiation result".
2.11.5 必须能够预先提供协商结果，但在这种情况下，AAA协议必须包括对“协商结果”的确认。
Even if the supported packages of a peer are configured, this must be confirmed before assuming both sides are similarly configured.
即使配置了对等机支持的包，也必须在假定双方配置类似之前进行确认。
2.11.6 For each application making use of a AAA protocol, there MUST be one inter-operable IETF standards-track specification of the authorization package types that are "mandatory to implement".
2.11.6 对于使用AAA协议的每个应用程序，必须有一个可互操作的IETF标准跟踪“强制实施”的授权包类型规范。
This requirement assures that communicating peers can count on finding at least one IETF specified inter-operable AAA protocol dialect provided they are doing authorization for a common application specific problem domain. This does not preclude the negotiation of commonly understood but private AAA protocol authorization package types (e.g. vendor specific).
此要求确保通信对等方可以指望找到至少一种IETF指定的可互操作AAA协议方言，前提是他们正在对常见的特定于应用程序的问题域进行授权。这并不排除协商通常理解但私有的AAA协议授权包类型（例如特定于供应商）。
2.11.7 It SHOULD also be possible to rank AAA negotiation options in order of preference.
2.11.7 还可以按照优先顺序对AAA谈判选项进行排序。
This states that, when negotiating, peers must be able to indicate preferences as well as capabilities.
这表明，在谈判时，对等方必须能够指出偏好和能力。
2.11.8 The negotiation mechanisms used by AAA protocols SHOULD NOT be vulnerable to a "bidding-down" attack.
2.11.8 AAA协议使用的协商机制不应容易受到“向下竞价”攻击。
A "bidding-down" attack is where an attacker forces the negotiating parties to choose the "weakest" option available. This is analogous to forcing 40-bit encryption on a link. The requirement highlights that protocol support is needed to prevent such attacks, for example by including the negotiation messages as part of a later MAC calculation, if authentication has produced a shared secret.
“出价下降”攻击是指攻击者迫使谈判各方选择可用的“最弱”选项。这类似于在链路上强制进行40位加密。该要求强调了需要协议支持来防止此类攻击，例如，如果身份验证产生了共享秘密，则需要将协商消息作为后续MAC计算的一部分。
2.11.9 A peer MUST NOT send an attribute within an authorization package or attribute that was not agreed to by a prior successful negotiation. If this AAA protocol violation occurs, then it MUST be possible to send an error indication to the misbehaving peer, and generate an error indication to the network operator.
2.11.9 对等方不得发送未经先前成功协商同意的授权包或属性中的属性。如果发生此AAA协议冲突，则必须能够向行为不端的对等方发送错误指示，并向网络运营商生成错误指示。
2.11.10 A peer MUST declare all of the sets of the authorization packages that it understands in its initial negotiation bid message.
2.11.10 对等方必须在其初始协商出价消息中声明其理解的所有授权包集。
This document includes specific security requirements.
本文件包括具体的安全要求。
This document does not state any detailed requirements for the interplay with authentication, accounting or accountability (audit). A AAA protocol, which meets all of the above requirements, may still leave vulnerabilities due to such interactions. Such issues must be considered as part of AAA protocol design.
本文件未说明与认证、会计或责任（审计）相互作用的任何详细要求。满足上述所有要求的AAA协议仍可能因此类交互而留下漏洞。这些问题必须作为AAA协议设计的一部分加以考虑。
[FRMW] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Framework", RFC 2904, August 2000.
[FRMW]Vollbrecht，J.，Calhoun，P.，Farrell，S.，Gommans，L.，Gross，G.，de Bruijn，B.，de Laat，C.，Holdrege，M.和D.Spence，“AAA授权框架”，RFC 29042000年8月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[RFC2138]Rigney，C.，Rubens，A.，Simpson，W.和S.Willens，“远程认证拨入用户服务（RADIUS）”，RFC 21381997年4月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", RFC 2277, January 1998.
[RFC2277]Alvestrand，H.，“IETF字符集和语言政策”，RFC2277，1998年1月。
[SAMP] 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.
[SAMP]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月。
Authors' Addresses
作者地址
Stephen Farrell Baltimore Technologies 61/62 Fitzwilliam Lane Dublin 2, IRELAND
Stephen Farrell Baltimore Technologies 61/62 Fitzwilliam Lane都柏林2号，爱尔兰
Phone: +353-1-647-7300
Fax: +353-1-647-7499
EMail: stephen.farrell@baltimore.ie
Phone: +353-1-647-7300
Fax: +353-1-647-7499
EMail: stephen.farrell@baltimore.ie
John R. Vollbrecht Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA
John R.Vollbrecht Interlink Networks，Inc.美国密歇根州安阿伯市科技大道775号200室，邮编：48108
Phone: +1 734 821 1205
Fax: +1 734 821 1235
EMail: jrv@interlinknetworks.com
Phone: +1 734 821 1205
Fax: +1 734 821 1235
EMail: jrv@interlinknetworks.com
Pat R. Calhoun Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA
Pat R.Calhoun网络和安全研究中心，太阳实验室太阳微系统公司，美国加利福尼亚州门罗公园网络圈15号，邮编94025
Phone: +1 650 786 7733
Fax: +1 650 786 6445
EMail: pcalhoun@eng.sun.com
Phone: +1 650 786 7733
Fax: +1 650 786 6445
EMail: pcalhoun@eng.sun.com
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 Phone: +31 30 2534585 Phone: +31 30 2537555 EMail: delaat@phys.uu.nl
乌得勒支大学物理与天文系，荷兰乌得勒支3584CC电话：+31 30 2534585电话：+31 30 2537555电子邮件：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编辑功能的资金目前由互联网协会提供。