组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
译者：郭立群（guoliqun guoliqun@sina.com）
译文发布时间：2001-11-24
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。
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 授权要求
（RFC2906——AAA Authorization Requirements）
本备注状态
本备注为Internet社区提供信息，并不列入任何的Internet标准中。本备注的发行没有限
制。
版权通告
Copyright (C) The Internet Society (2000). All Rights Reserved.
摘要
本文档详述了验证授权记账协议为支持Internet授权服务而必须满足的需求。这些需求
是通过研究一系列应用得出的，包括移动IP，漫游操作（roamops，Roaming Operating） 以
及其他应用。
目录
1. 介绍 2
2. 需求 2
2.1 授权信息 3
2.2 授权信息的安全 4
2.3 时间 5
2.4 拓扑 6
2.5 应用代理 7
2.6 信任模式 7
2.7 不精确的处理 8
2.8 管理 8
2.9 在线字节 9
2.10 接口 9
2.11 协商 10
3. 需要考虑的安全问题 10
4. 参考书目 10
作者的地址 11
完整版权声明 13
1. 介绍
本文档是一系列三个文档中的一个，这些文档是AAAarch RG（AAA architecture Research
Group）考虑用来处理AAA协议授权需求。这三个文档是：
AAA授权框架——AAA Authorization Framework [FRMW]
AAA授权需求——AAA Authorization Requirements （本文档）
AAA 授权应用范例——Authorization Application Examples [SAMP]
本备注的工作是由原来的IETF AAA工作组授权分组完成的。当AAA工作组的charter
转向移动IP和NAS后，就在IRTF中特许设立了AAA结构研究小组继续和扩大由授权分
组开始的结构工作。本备注是这个分组建立的四个中的一个，是AAA结构研究小组开展进
一步工作的起点。这是一项仍在进行中的工作，发布的目的是使AAA结构研究小组和其它
这个领域的工作能够利用它，而不是对结构或需求的最后描述。
写这篇文档的过程是通过分析基于对AAA授权框架[FRMW]一般理解的[SAMP]的需求
完成的。本文档假设读者熟悉授权中包含的两个通用问题，而且读者会从阅读[FRMW] 中
受益，例如从中可发现一些术语的定义。
文档中关键词"MUST", "REQUIRED", "SHOULD", "RECOMMENDED"和"MAY"要按照
RFC2119的定义解释。
2. 需求
需求根据方便的原则按照标题分成组，但这个分组并不重要。
文档中使用的一些技术术语的定义和解释可在[FRMW] 中找到。
每个需求都以一种简洁的（通常是一个句子或两个句子）状态表示，大多数后面会跟有
一段说明材料，有时还会包括例子。完整描述的例子可在[SAMP]中找到。
这里出现的需求不会故意弄成“直交的”，也就是说，有些会和其它的重复和交迭。
2.1 授权信息
2.1.1 必须能够在有关请求者、请求的服务/方法和操作环境（授权信息）这些信息的基础
上得出授权决定。要求AAA协议传输此信息。
这简单地说明了对一个协议的要求和从输入中得到的基于请求者、请求的资源以及环境
的访问决定功能。
2.1.2 必须有可能把授权信息表示为一组属性，也许可能把授权信息表示为对象。
这说明授权信息必须可分解为属性集，这并不意味着表示属性需要任何特殊的机制。
2.1.3 必须有可能把授权信息打包，这样就可在AAA和应用协议的单个消息中携带多个
服务或应用的授权信息。
这说明那些总是为每个服务/应用请求单个AAA消息/事务的协议是不满足要求的。例如，
应当可使单个AAA消息/事务足够用来既允许网络也允许应用访问。
2.1.4 应当定义标准属性类，这些类同许多Internet 应用/服务有关（例如，一致性信息，
组信息等）。
用于许多上下文中的很多属性应当只定义一次，以便改善互操作性和阻止复制的努力。
2.1.5 授权决定不可局限在一致性信息基础上，也就是AAA协议必须支持非一致性信息
的使用，比如支持基于访问控制的任务（role based access control，RBAC）。
要求支持基于许可、任务、组和其它信息的授权。只携带一致性信息的AAA协议将不
满足需求。
2.1.6 授权数据除了包含最终实体直接拥有的属性外，可能还包含限制。
这说明某些属性不是简单地表示一个实体的属性，例如IR 1,000的开销限制不是一个实
体的固有属性。这也对访问决定功能有影响，因为进行比较不是一个简单的等式匹配。
2.1.7 必须可使其它（非AAA）协议能定义它们自己的可携带在一个AAA或应用协议授
权包中属性类。
这说明，对一个授权决定至关重要的属性可能是依赖应用协议的。例如，将会需求许多
RFC2138定义的属性类和对这些属性的语义学支持。当然，只有那些知道更多属性类的AAA
实体才可使用它们。
2.1.8 应当允许系统管理员定义他们自己的可携带在一个AAA或应用协议授权包中属性
类。
这说明，对一个授权决定至关重要的属性可能依赖一个封闭环境。例如，许多组织有定
义很好的资历计划，可用来决定晋级级别。当然，只有那些知道更多属性类的AAA实体才
可使用它们。
2.1.9 应当可以在没有属性命名空间的中心管理和控制下定义新的属性类。
如果要避免在属性类分配中的冲突，就需要某种集中或分布的定位计划。然而，一个总
是要求使用这样的集中定位的AAA协议将不满足要求。当然，冲突会尽可能的避免。
2.1.10 必须可能定义属性类，使得单个AAA消息中一个属性的实例可有多个值。
这说明不允许消息/事务中的一个属性有多个实例的协议不能满足要求。例如，应当可能
有一个“组”属性，它包含多个组名（或数字或任何其它东西）。
2.1.11 必须可以在“安全域”或“权限”基础上区分相同授权属性类或值的不同实例。
这就认可了能够区分那些不仅仅基于值的属性是重要的。例如，所有的NT域（使用英
语）都有一个管理员组，所以需要一个访问决定功能够决定请求者是属于这些组中的哪一个。
2.1.12 AAA协议必须指定更新规则的机制，这些规则是用来控制授权决定的。
这说明不能提供分布授权规则的AAA协议是不充分的。例如，这可用来下载ACLs到
PDP。
注意，这并不意味着必须总是使用此AAA协议机制，简单地说就是它们必须在使用时
可获得。特别的，在通常情况下会使用存储在可信任库（通常是LDAP服务器）里的授权
规则，而不是这样的一个AAA协议机制。这个要求在两种情况下都不要求授权规则有标准
格式，仅仅是有一个传输它们的机制。
2.1.13 AAA协议必须允许AAA实体链包含在授权决定中。
这说明，多于一个的AAA服务器必须包含在单个授权决定中。这种情况的发生可能是
由于决定通过多个“域”传播或是为了把授权分布在单个“域”中。
2.1.14 AAA协议必须允许中间AAA实体可往AAA请求或响应中增加它们自己本地的授权
信息。
这说明，当有多个AAA实体包含在授权决定中时，每个AAA实体都可以通过增加更多
的信息或处理部分信息来实现对AAA消息的利用。
2.1.15 AAA实体既可以单独使用又可以和应用实体综合。
这说明，AAA实体既可以作为AAA服务器实现，也可以和应用实体综合。
2.1.16 AAA协议必须支持规则的建立和编码，这些规则在一台基于另一个AAA服务器发布
的属性的AAA服务器上激活。发出请求的AAA服务器的授权级别可以管理关于属性的视
图。
这说明，一个AAA实体必须可以把授权信息分布到另一个上，而且说明接收这个规则
的AAA实体可以只看作问题的部分。
2.1.17 AAA协议必须支持关键和非关键属性类。
这和在公钥证书扩展中使用关键程度标志是类似的。
2.1.18 AAA协议必须允许授权规则按照已评估的其它授权规则组合来表示。
例如，如果请求者是备份用户组而不是管理员组的成员时才准许访问。注意，这个要求
没有说明支持何种类型的组合。
2.1.19 应当可以基于请求者的地理位置、服务或AAA实体做出授权决定。
这仅是一个授权属性类的例子，明显是因为它要求不同的基础实现机制。
2.1.20 应当可以基于请求者、服务或AAA实体使用的身份或装备做出授权决定。
这仅是一个授权属性类的例子，明显是因为它可能要求不同的基础实现机制（如果不可
利用IPSec）。
2.1.21 当一个给定的属性有多个实例时，一定有个明确的机制使得接收对可决定指定实例的
值。
2.2 授权信息的安全
2.2.1 必须使授权信息可安全地在AAA和应用协议中通讯。必须指定机制保持信息的真实
性、完整性和保密性。
这说明必须有很好定义的方法保护授权信息的安全，但并不总是需要使用这样的方法。
当然，是否支持为了一致性而要求的这些机制是开放的。特别的，必须提供机制禁止链中间
的服务管理员读取或改变在另外两个AAA实体间的授权信息。
2.2.2 AAA协议必须允许使用授权信息的适当安全级别。AAA协议必须支持数据完整性/一
致性等的高安全机制和低安全机制。
重要的是AAA协议不要造成负担太大的安全开销，因而并不总需要使用指定的安全机
制（虽然不使用它们可能会影响授权决定）。
2.2.3 安全要求可能根据授权信息包的不同部分而不同。
某些部分可能要求一致性和完整性，某些部分可能只要求完整性。这有力地说明了需要
类似选择字段的安全机制。例如，获得访问一个网络所需要的信息必须是明确的，有时访问
网络中一个应用所需的信息必须在AAA协议中加密。
2.2.4 AAA协议必须提供机制来防止中间管理员破坏安全。
阻止中间人攻击，比如中间管理员改变传送中的AAA消息，这是个基本要求。
2.2.5 AAA协议必不能打开基于重放授权信息的重放攻击。
例如，AAA协议不应当允许扩散法攻击，否则攻击者重放AAA消息，而接收者需要使
用大量的CPU或通讯才能探测出重放。
2.2.6 AAA协议必须能够平衡任何实体对验证机制，它们可能已经应用－这可提供额外的确
认，保证授权信息的拥有者和验证实体是相同的。例如，如果IPSec提供了足够证明，那么
就可以省略AAA协议验证。
2.2.7 授权信息包可能要求端到端的机密性、完整性、对等实体验证或认可。
这说明必须为部分AAA消息提供机密性（resp.其它安全服务），即使是通过其它AAA
实体传输。当然允许这样的AAA消息也可以包含非机密性（resp.其它安全服务）部分。另
外，中间的AAA实体认为自己在应用于AAA消息其余部分的端到端安全服务中是终结点。
2.2.8 AAA协议即使在不需要验证实体对的情况下（比如，在一个安全LAN中，网络地址
就完全可以决定），也必须是可用的。
这个要求（在某种意义上和2.2.6相反）指明需要的灵活程度，以便使AAA协议可在很
广泛的应用/服务范围内使用。
2.2.9 AAA协议必须为所有的协议选项指定“安全”缺省值。AAA实体的实现必须使用这
些“安全”缺省值，除非另外配置/管理。
这说明配置必须是“安全的”，例如，如果不配置AAA实体，那么授权决定应当拒绝访
问。注意，对“安全”的解释应当根据情况的不同而不同，虽然原则是相同的。
2.3 时间
2.3.1 授权信息必须是及时的，也就是说信息必须有期限，并且在某种情况下可以在期满以
前撤销。
这说明授权信息本身在任何时候都不认为是有效的，授权信息的每个部分必须与清楚的
或绝对的有效期或生存期相关联。
2.3.2 AAA协议必须提供在特定权限下，撤销授权信息的机制。
虽然有效期或生命期较长，所以可能需要撤销授权信息，例如当一个人离开公司时。注
意，这个需求并不指定一个特别的撤销规划，所以不需要黑名单或CRLs。
2.3.3 一组属性可以有一个关联的有效期，使得这组属性只能在此期间用来做授权决定。有
效期可以相对较长（例如，几个月）或较短（几个小时或几分钟）。
这说明有时需要明确的有效期字段。
2.3.4 授权决定可能是对时间敏感的。必须有对诸如“工作时间”或等价概念的支持。
这说明AAA协议必须能够支持时间控制属性的传输，虽然并不要求AAA协议必须包含
一种表示“工作时间”类约束的标准方法。
2.3.5 必须可以支持产生依赖于时间的结果的授权决定。
例如，授权结果可能是服务应当在一定时期内提供。在这时，AAA协议必须能够传输这
个信息，可能是作为授权决定的指定结果，或者是作为附加的“服务终止”AAA消息以后
传输。
2.3.6 必须支持授权信息在授权决定之前发布的模型，而不是在接近做出授权决定时。
这样作是为了支持预付费（和预订相反）情况（如，VoIP）。
2.3.7 必须可以支持在服务请求之前做出授权决定的模型。
这是因为某些应用程序，如备份，它们的操作安排到了将来的日子。还包括那些需要预
留资源的应用。
2.3.8 AAA机制必须允许授权信息携带时间戳信息（例如，用于不可否认服务）。
PKIX WG（Public-Key Infrastructure (X.509) WG (pkix-wg)）正在开发时间戳协议，可作
为不可否认解决方案的一部分。在某些环境下，某些AAA协议消息必须带有时间戳（由可
信任的权威加盖时间戳）并且时间戳在随后的AAA消息中转发。
2.4 拓扑
2.4.1 AAA协议必须能够支持使用推、拉和代理模式。
这说明只支持一个模式的协议，比如拉，不能满足所有应用的需求。模式在[FRMW]中
定义。
2.4.2 在包含多个AAA实体的事务/会话中，每一“跳”可以使用一个不同推/拉/代理模式。
例如，对于移动IP来说，一个“外来”AAA服务器可以从代理程序拉到授权信息，然
而代理程序可以把某些授权信息推到一个“本地”AAA服务器。
2.4.3 AAA协议必须适用于那些应用和服务，它们包含在应用或AAA协议中的实体属于不
同的（安全的）域。
这说明对于任何AAA协议消息必须可以跨安全或管理域边界。典型的，当跨越这样的
边界时，使用高安全级别，并且记账机制也必须更加严格。
2.4.4 AAA协议必须支持漫游。
这里的漫游也可以被认为是“离开家”操作。例如，这是移动IP的基本需要。
2.4.5 AAA协议应当支持动态移动性。
这里的动态移动是指，客户端从一个域移至另一个域，而不需要完全重建，保留了所有
的AAA会话信息。
2.4.6 授权决定必须可以在请求者和网络有任何其它连接以前做出。
例如，这意味着请求者不可以在网络中游走，随意读取东西，必须通过应用/服务或通过
中间AAA实体发出请求。AAA协议不应当将此服务器暴露给拒绝服务攻击。
2.4.7 AAA必须支持使用中间AAA实体，它们参与授权事务，但是并不“拥有”任何最终
实体或授权数据。
在某些环境中（如漫游操作），这些实体称为代理（虽然它们和QoS环境中的带宽代理
不相同）。
2.4.8 AAA协议可支持中间AAA实体返回一个转发地址给请求者或AAA实体的情况，使得
请求者或发起AAA实体可以和其它AAA实体联系。
这个需求考虑AAA服务器会有路由问题，并且要求AAA协议能够避免这样的路由。例
如，对于移动IP，需要一个代理，使得部分地允许外地和本地AAA服务器获得联系。
2.4.9 对于访问决定功能必须可以发现请求者的AAA服务器。如果请求者提供用于发现过
程的信息，然后访问决定功能必须能够验证此信息是可信的。
这说明不仅AAA服务器必须能够互相发现，而且有时一个应用实体也必须发现一个适
当的AAA服务器。
2.5 应用代理
2.5.1 AAA协议必须支持应用使用代理，也就是说，应用实体(C) 产生一个服务请求，发到
对端(I)，并且这个中间(I)也发出一个代表客户(C)的服务请求，发往最终目标(T)。AAA协议
必须在T做出授权决定，依赖于C和/或I关联的授权信息。这个“应用代理”不能够往AAA
协议中引入新的安全缺陷。可以是任意长度的应用代理链。
注意，这个需求提到的是应用层代理，而不是AAA服务器链。例如，一个HTTP代理
链可以每个都想要限制它们提供给“外界”的服务内容。当HTTP GET消息从HTTP代理
到HTTP代理时，这个需求说明每个阶段做出的授权决定可依赖于浏览器用户，而不是说单
单地依赖于前面HTTP代理特性。当然可以只包含唯一地一个AAA服务器，或包含很多。
2.5.2 虽然是应用代理链，每个阶段的AAA协议可以是独立的，也就是说第一跳使用推模
式，第二跳使用拉模式，第三跳使用代理模式。
这只是重复说明前面的需求(2.4.7)，明确它在使用应用代理的时候也可以应用。
2.6 信任模式
2.6.1 AAA实体必须能够根据授权信息的种类确认其它AAA实体是否可信。
这和公钥基础结构中的需求是类似的：
仅仅因为某人能产生一个加密的正确公钥证书，并不意味着应当信任它们的任何东西，
尤其是，我可以因为某些目的信任这个发行者，但是对于其它的，则不一定信任。
2.6.2 AAA协议必须允许实体因为不同的目的而可信，信任不是一个要么全部信任要么全部
不信任的问题。
这联系起了打包(2.1.3)和信任(2.6.1) 需求。例如，一个AAA实体可以信任授权包的某些
部分，而不信任其它部分。
2.6.3 需要授权确认以便初始化和重新同步一个AAA实体。
这说明AAA实体可能需要处理某些AAA协议消息，以便初始化自己。特别的，AAA
实体可能需要在启动时检查前面的AAA消息仍然“有效”。
2.6.4 关闭某些服务时需要静态授权协商。
这和前面的2.6.5正好相反。它意味着一个AAA实体“告诉”另一个AAA实体，它前
面的AAA消息不再“有效”。参见2.3.2和2.7.6。
2.6.5 必须可以配置属于本地域的AAA实体，以便它们相互可信，但外部信任必须通过某
些AAA实体的指定子集配置。
这说明，出于效率和组织的原因，必须可以设置某些AAA服务器，通过它们处理所有
的“外部”AAA服务。还说明必须可以实现这个功能而不因为繁重的安全机制加重“仅用
于内部”AAA服务器的负担，仅仅是因为某些AAA服务器要处理外部关系。
2.6.6 链的中间AAA实体必须能够拒绝链上较前的实体认可的连接。
例如，对于移动IP，家庭网络可以批准一个连接，但是外来网络可以因为家庭网络选择
的设置而拒绝允许这个连接，比方说家庭网络拒绝付费。
2.6.7当正在处理一个会话而不破坏其它会话信息时，应当可以修改资源授权。
例如，一个“父”AAA服务器应当能够修改“子”AAA服务器管理的会话的授权状态，
比方说可以修改允许同时会话的最大数字。
2.7 不精确的处理
2.7.1 授权决定可能对上下文敏感，AAA协议必须允许这种决定。
这说明AAA协议需要支持那种依赖于（甚至可能仅仅依赖于）系统现有状态的授权。
例如，只允许七个会话，那么第七个决定依赖于现存的六个会话。因为上下文可能包括多个
服务，AAA协议很可能必须提供某些支持。
2.7.2 AAA协议应当既支持事务授权，也支持会话连续授权。
这说明AAA实体必须保留状态和行为，状态指示出发生了什么情况。
2.7.3 在单一会话和事务中，必须能轮流对AAA消息进行验证、授权和记账。
这说明，一个会话可能必须使用初始的验证、授权和记账AAA消息，但同时还可能必
须包括每隔30秒重新验证，或记帐AAA消息连续“滴答－滴答”。
2.7.4 授权决定可能导致一个“未准备好”应答。
这说明是和否不是授权决定的唯一结果。特别的，如果AAA实体不能给出一个决定，
那么就会返回这样的一个结果。这和PKI管理协议中有时对公钥证书请求的处理非常类似。
2.7.5 一个AAA实体可以重定向一个接收到的AAA请求。
这说明，如果实体“a”询问“b”，然后“b”可能说：“别问我，问‘c’”。这和HTTP
重定向（状态码307）非常类似。
2.7.6 AAA协议应当允许一个AAA实体“取消”一个授权。
期望AAA协议支持AAA实体能够发信号给一个应用或其它AAA实体，指出一个授权
（可能是以前由一个第三方AAA实体授予的）不再有效。
2.8 管理
2.8.1必须能够代表终结实体和AAA实体管理授权数据。
这个需求指出AAA的管理必须作为协议设计的部分考虑，一个要求所有AAA实体独立
于所有其它AAA实体行动的AAA协议不满足要求。
2.8.2 应当支持所有特性的集中管理。
应当可以做到（如果满足域的需求）集中或分布AAA的管理。
2.8.3 AAA协议应当支持用户（而不是管理员）有权批准一个事务。
例如，一个用户可能想控制不吃午餐肉的方法或有权决定是否购买。在这种情况下，用
户在某种程度说，是一个管理员。
2.8.4 一个AAA实体可以为另一个AAA实体创建授权规则。
这是适当支持权利授予的需要，但是即便是允许，也必须以安全的方式完成。
2.8.5 当一个AAA实体链上的AAA实体维持一个会话失败的状态时，AAA协议应当支持
故障恢复。
例如，在网络访问情形下，可能需要一个已经崩溃的AAA服务器能够确定有多少个会
话在处理，以便做出“下一个”授权决定。
2.8.6 一个AAA实体应当可以询问另一个AAA实体的授权状态。
这是故障恢复过程的需要。
2.8.7 AAA协议必须能支持服务器组件的“热fail-over”而不丢失状态信息。
这说明AAA协议必须能支持当一个服务器不再工作时，另一个服务器能自动“激活”
而不丢失重要状态信息。
2.9 在线字节
2.9.1 需要时分离授权和验证，但是AAA协议必须允许单个消息既请求验证也请求授权。
AAA协议必须允许授权和验证的分离，以便它们使用不同的机制。这说明有时需要在同
一个消息中携带两类信息。
2.9.2 为了尽量减少资源的使用（例如，减少往返），必须能够把AAA PDU嵌入其它协议中。
这说明必须定义AAA协议授权包，以便它们可以携带在其它协议中。例如，为了引用
授权包而依靠AAA协议头信息可能使得协议不能满足需求。
2.9.3 AAA协议可以提供复制状态信息的机制。
在要求热备份的情况下，需要这点支持系统恢复。注意，AAA协议当然从属于正规协议
设计需求，也要求可靠性、没有单点故障等，即使这里没有全部指出。
2.9.4 AAA协议应当允许有可能在AAA协议和其它传统AAA相关协议之间实现网关功能。
例如，很可能需要对RFC2138作为传统协议的某些形式的支持。当然，使用这样一个网
关，在某种程度上总是意味着通过网关路由的事务没有满足某些需求（如，端到端的安全性）。
这并不暗示说，这样的网关功能需要一台单独的服务器。
2.9.5 AAA协议必须能够支持使用大范围原语数据类型，包括RFC2277。
例如，无疑总是需要传输不同长度、有符号和无符号的整数，可能还包含多精确度整数。
可能还需要支持符合ANSI IEEE 754-1985的浮点运算。
2.9.6 AAA协议传输应当支持优化主机对之间数据流里面小包的长期交换。
典型地，NASes有大量地事务/秒，因此AAA协议必须允许控制请求流使得服务器能更
有效地使用它的接受缓存。
2.9.7 AAA协议必须对提供负载均衡的支持。
如果一个实体对不能接受任何最近的请求，那么AAA协议必须允许在实体对之间实现
请求负载的均衡。
2.10 接口
2.10.1 应当可以使授权数据用于应用的目的。
例如，在访问web时，如果授权数据包含一个组名、机制，使得应用可获得此数据，以
便修改最初想要请求的URL。
2.10.2 应当可以使授权数据能用于调整一个请求的响应。
例如，访问web时，清除属性值可能影响HTTP响应消息的内容。
2.10.3 AAA协议应当能够在请求者没有提前注册（至少是为了授权目的，但是也可以是为
了验证目的）的情况下操作。
这在衡量有多个请求者的AAA解决方案时是必要的。.
2.10.4 AAA协议必须能够支持授权和记账机制之间的连接。
2.10.5 AAA协议必须能够支持可记帐（审计/不可否认）机制。
有时，一个授权决定在请求者尚未验证的情况下作出。在这种情况下，使用的授权数据
必须和审计或其它责任机制相联系。注意：这个需求不要求必须支持数字签名或其它不可否
认解决方案的某些部分。
2.11 协商
2.11.1 AAA协议必须支持访问授权包集合的能力，以便允许双方协商得到一个共同的集合。
给定的双方可能支持不同的授权属性类型和包的组合，这个需求说明要求协议确保双方
使用两方都支持的包。
2.11.2 必须能够协商两个不直接通讯的AAA实体间的授权包。
这说明，例如在包含一个代理程序的情况下，目的AAA服务器可能仍然需要协商。
2.11.3 如果协商结果不能得出一个可接受的共同支持集合，那么访问必须被拒绝。
例如，如果服务器不能理解请求者的属性，那么就不能授予访问权限。
2.11.4 如果协商结果不能得出一个可接受的共同支持集合，那么应当产生一个错误指示发送
给另外的AAA实体。
如果协商失败，那么经常需要管理员进行干预，并且应当提供支持的协议。
2.11.5 可以提前规定协商的结果，但是这种情况下，AAA协议必须包含对“协商结果”的
确认。
即使配置了双方支持的包，这也必须在假设两端配置相同前进行确认。
2.11.6 对于每一个使用AAA协议的应用来说，必须有一个“强制执行”的、可互操作的授
权包IETF标准追踪规范。
这个需求保证通讯双方能够指望发现提供了至少一个IETF指定的可互操作的AAA协
议，它们完成对一个共同应用的特殊问题域的授权。这不排除对共同理解，但专用的AAA
协议授权包类型（比方说，厂商指定的细节）的协商。
2.11.7 还应当可以按照优先权的顺序对AAA协商选项进行排列。
这说明，当协商时，双方必须能够标识优先权以及性能。
2.11.8 AAA协议使用的协商机制不应当易于受到“bidding-down”攻击。
"bidding-down"攻击是指攻击者强迫协商双方选择可得到的“最弱”选项。这和在一个链
接上强迫40比特加密是类似的。这个需求强调需要协议支持以阻值此类攻击，举例来说，
如果验证已经产生了一个共享的密码，那么可以把协商消息作为后面MAC计算的部分。
2.11.9 通讯双方不能发送前面成功协商不同意的授权包和属性类。如果发生这样的AAA协
议破坏，那么必须要给错误行动的对方发送错误指示，并且给网络操作者产生一个错误指示。
2.11.10 通讯双方必须在初始化协商查询包中公布所有它理解的授权包集合。
3. 需要考虑的安全问题
本文档包含特定的安全需求。
本文档不声明任何关于验证、记帐或可记帐性（审计）之间相互影响的详细需求。
一个满足所有以上这些需求的AAA协议，可能因为这样的互操作而导致脆弱性。这些
问题必须当作AAA协议设计的一部分加以考虑。
4. 参考书目
[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.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026,
October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP
14, RFC 2119, March 1997.
[RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication
Dial In User Service (RADIUS)", RFC 2138, April 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", RFC 2277,
January 1998.
[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.
作者的地址
Stephen Farrell
Baltimore Technologies
61/62 Fitzwilliam Lane
Dublin 2,
IRELAND
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
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
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
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
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
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
Matt Holdrege
ipVerse
223 Ximeno Ave.
Long Beach, CA 90803
EMail: matt@ipverse.com
David W. Spence
Interlink Networks, Inc.
775 Technology Drive, Suite 200
Ann Arbor, MI 48108
USA
Phone: +1 734 821 1203
Fax: +1 734 821 1235
EMail: dspence@interlinknetworks.com
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
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.
RFC2906——AAA Authorization Requirements AAA授权要求
13
RFC文档中文翻译计划