本备注状态本备注为Internet社区提供信息，并不列入任何的Internet标准中。本备注的发行没有限制。版权通告Copyright(C)TheInternetSociety(2000).AllRightsReserved.摘要本文档详述了验证授权记账协议为支持Internet授权服务而必须满足的需求。这些需求是通过研究一系列应用得出的，包括移动IP，漫游操作（roamops，RoamingOperating）以及其他应用。目录1.介绍 22.需求 22.1授权信息 32.2授权信息的安全 42.3时间 52.4拓扑 62.5应用代理 73.需要考虑的安全问题 104.参考书目 10作者的地址 11完整版权声明 121.介绍本文档是一系列三个文档中的一个，这些文档是AAAarchRG（AAAarchitectureResearchGroup）考虑用来处理AAA协议授权需求。这三个文档是：AAA授权框架——AAAAuthorizationFramework[FRMW]AAA授权需求——AAAAuthorizationRequirements（本文档）AAA授权应用范例——AuthorizationApplicationExamples[SAMP]本备注的工作是由原来的IETFAAA工作组授权分组完成的。当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协议必须支持非一致性信息的使用，比如支持基于访问控制的任务（rolebasedAccesscontrol，RBAC）。要求支持基于许可、任务、组和其它信息的授权。只携带一致性信息的AAA协议将不满足需求。2.1.6授权数据除了包含最终实体直接拥有的属性外，可能还包含限制。这说明某些属性不是简单地表示一个实体的属性，例如IR1,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.12AAA协议必须指定更新规则的机制，这些规则是用来控制授权决定的。这说明不能提供分布授权规则的AAA协议是不充分的。例如，这可用来下载ACLs到PDP。注重，这并不意味着必须总是使用此AAA协议机制，简单地说就是它们必须在使用时可获得。非凡的，在通常情况下会使用存储在可信任库（通常是LDAP服务器）里的授权规则，而不是这样的一个AAA协议机制。这个要求在两种情况下都不要求授权规则有标准格式，仅仅是有一个传输它们的机制。2.1.13AAA协议必须答应AAA实体链包含在授权决定中。这说明，多于一个的AAA服务器必须包含在单个授权决定中。这种情况的发生可能是由于决定通过多个“域”传播或是为了把授权分布在单个“域”中。2.1.14AAA协议必须答应中间AAA实体可往AAA请求或响应中增加它们自己本地的授权信息。这说明，当有多个AAA实体包含在授权决定中时，每个AAA实体都可以通过增加更多的信息或处理部分信息来实现对AAA消息的利用。2.1.15AAA实体既可以单独使用又可以和应用实体综合。这说明，AAA实体既可以作为AAA服务器实现，也可以和应用实体综合。2.1.16AAA协议必须支持规则的建立和编码，这些规则在一台基于另一个AAA服务器发布的属性的AAA服务器上激活。发出请求的AAA服务器的授权级别可以治理关于属性的视图。这说明，一个AAA实体必须可以把授权信息分布到另一个上，而且说明接收这个规则的AAA实体可以只看作问题的部分。2.1.17AAA协议必须支持要害和非要害属性类。这和在公钥证书扩展中使用要害程度标志是类似的。2.1.18AAA协议必须答应授权规则按照已评估的其它授权规则组合来表示。例如，假如请求者是备份用户组而不是治理员组的成员时才准许访问。注重，这个要求没有说明支持何种类型的组合。2.1.19应当可以基于请求者的地理位置、服务或AAA实体做出授权决定。这仅是一个授权属性类的例子，明显是因为它要求不同的基础实现机制。2.1.20应当可以基于请求者、服务或AAA实体使用的身份或装备做出授权决定。这仅是一个授权属性类的例子，明显是因为它可能要求不同的基础实现机制（假如不可利用IPSec）。2.1.21当一个给定的属性有多个实例时，一定有个明确的机制使得接收对可决定指定实例的值。2.2授权信息的安全2.2.1必须使授权信息可安全地在AAA和应用协议中通讯。必须指定机制保持信息的真实性、完整性和保密性。这说明必须有很好定义的方法保护授权信息的安全，但并不总是需要使用这样的方法。当然，是否支持为了一致性而要求的这些机制是开放的。非凡的，必须提供机制禁止链中间的服务治理员读取或改变在另外两个AAA实体间的授权信息。2.2.2AAA协议必须答应使用授权信息的适当安全级别。AAA协议必须支持数据完整性/一致性等的高安全机制和低安全机制。重要的是AAA协议不要造成负担太大的安全开销，因而并不总需要使用指定的安全机制（虽然不使用它们可能会影响授权决定）。2.2.3安全要求可能根据授权信息包的不同部分而不同。某些部分可能要求一致性和完整性，某些部分可能只要求完整性。这有力地说明了需要类似选择字段的安全机制。例如，获得访问一个网络所需要的信息必须是明确的，有时访问网络中一个应用所需的信息必须在AAA协议中加密。2.2.4AAA协议必须提供机制来防止中间治理员破坏安全。阻止中间人攻击，比如中间治理员改变传送中的AAA消息，这是个基本要求。2.2.5AAA协议必不能打开基于重放授权信息的重放攻击。例如，AAA协议不应当答应扩散法攻击，否则攻击者重放AAA消息，而接收者需要使用大量的CPU或通讯才能探测出重放。2.2.6AAA协议必须能够平衡任何实体对验证机制，它们可能已经应用－这可提供额外的确认，保证授权信息的拥有者和验证实体是相同的。例如，假如IPSec提供了足够证实，那么就可以省略AAA协议验证。2.2.7授权信息包可能要求端到端的机密性、完整性、对等实体验证或认可。这说明必须为部分AAA消息提供机密性（resp.其它安全服务），即使是通过其它AAA实体传输。当然答应这样的AAA消息也可以包含非机密性（resp.其它安全服务）部分。另外，中间的AAA实体认为自己在应用于AAA消息其余部分的端到端安全服务中是终结点。2.2.8AAA协议即使在不需要验证实体对的情况下（比如，在一个安全LAN中，网络地址就完全可以决定），也必须是可用的。这个要求（在某种意义上和2.2.6相反）指明需要的灵活程度，以便使AAA协议可在很广泛的应用/服务范围内使用。2.2.9AAA协议必须为所有的协议选项指定“安全”缺省值。AAA实体的实现必须使用这些“安全”缺省值，除非另外配置/治理。这说明配置必须是“安全的”，例如，假如不配置AAA实体，那么授权决定应当拒绝访问。注重，对“安全”的解释应当根据情况的不同而不同，虽然原则是相同的。2.3时间2.3.1授权信息必须是及时的，也就是说信息必须有期限，并且在某种情况下可以在期满以前撤销。这说明授权信息本身在任何时候都不认为是有效的，授权信息的每个部分必须与清楚的或绝对的有效期或生存期相关联。2.3.2AAA协议必须提供在特定权限下，撤销授权信息的机制。虽然有效期或生命期较长，所以可能需要撤销授权信息，例如当一个人离开公司时。注意，这个需求并不指定一个非凡的撤销规划，所以不需要黑名单或CRLs。2.3.3一组属性可以有一个关联的有效期，使得这组属性只能在此期间用来做授权决定。有效期可以相对较长（例如，几个月）或较短（几个小时或几分钟）。这说明有时需要明确的有效期字段。2.3.4授权决定可能是对时间敏感的。必须有对诸如“工作时间”或等价概念的支持。这说明AAA协议必须能够支持时间控制属性的传输，虽然并不要求AAA协议必须包含一种表示“工作时间”类约束的标准方法。2.3.5必须可以支持产生依靠于时间的结果的授权决定。例如，授权结果可能是服务应当在一定时期内提供。在这时，AAA协议必须能够传输这个信息，可能是作为授权决定的指定结果，或者是作为附加的“服务终止”AAA消息以后传输。2.3.6必须支持授权信息在授权决定之前发布的模型，而不是在接近做出授权决定时。这样作是为了支持预付费（和预订相反）情况（如，VoIP）。2.3.7必须可以支持在服务请求之前做出授权决定的模型。这是因为某些应用程序，如备份，它们的操作安排到了将来的日子。还包括那些需要预留资源的应用。2.3.8AAA机制必须答应授权信息携带时间戳信息（例如，用于不可否认服务）。PKIXWG（Public-KeyInfrastrUCture(X.509)WG(pkix-wg)）正在开发时间戳协议，可作为不可否认解决方案的一部分。在某些环境下，某些AAA协议消息必须带有时间戳（由可信任的权威加盖时间戳）并且时间戳在随后的AAA消息中转发。2.4拓扑2.4.1AAA协议必须能够支持使用推、拉和代理模式。这说明只支持一个模式的协议，比如拉，不能满足所有应用的需求。模式在[FRMW]中定义。2.4.2在包含多个AAA实体的事务/会话中，每一“跳”可以使用一个不同推/拉/代理模式。例如，对于移动IP来说，一个“外来”AAA服务器可以从代理程序拉到授权信息，然而代理程序可以把某些授权信息推到一个“本地”AAA服务器。2.4.3AAA协议必须适用于那些应用和服务，它们包含在应用或AAA协议中的实体属于不同的（安全的）域。这说明对于任何AAA协议消息必须可以跨安全或治理域边界。典型的，当跨越这样的边界时，使用高安全级别，并且记账机制也必须更加严格。2.4.4AAA协议必须支持漫游。这里的漫游也可以被认为是“离开家”操作。例如，这是移动IP的基本需要。2.4.5AAA协议应当支持动态移动性。这里的动态移动是指，客户端从一个域移至另一个域，而不需要完全重建，保留了所有的AAA会话信息。2.4.6授权决定必须可以在请求者和网络有任何其它连接以前做出。例如，这意味着请求者不可以在网络中游走，随意读取东西，必须通过应用/服务或通过中间AAA实体发出请求。AAA协议不应当将此服务器暴露给拒绝服务攻击。2.4.7AAA必须支持使用中间AAA实体，它们参与授权事务，但是并不“拥有”任何最终实体或授权数据。在某些环境中（如漫游操作），这些实体称为代理（虽然它们和QoS环境中的带宽代理不相同）。2.4.8AAA协议可支持中间AAA实体返回一个转发地址给请求者或AAA实体的情况，使得请求者或发起AAA实体可以和其它AAA实体联系。这个需求考虑AAA服务器会有路由问题，并且要求AAA协议能够避免这样的路由。例如，对于移动IP，需要一个代理，使得部分地答应外地和本地AAA服务器获得联系。2.4.9对于访问决定功能必须可以发现请求者的AAA服务器。假如请求者提供用于发现过程的信息，然后访问决定功能必须能够验证此信息是可信的。这说明不仅AAA服务器必须能够互相发现，而且有时一个应用实体也必须发现一个适当的AAA服务器。2.5应用代理2.5.1AAA协议必须支持应用使用代理，也就是说，应用实体(C)产生一个服务请求，发到对端(I)，并且这个中间(I)也发出一个代表客户(C)的服务请求，发往最终目标(T)。AAA协议必须在T做出授权决定，依靠于C和/或I关联的授权信息。这个“应用代理”不能够往AAA协议中引入新的安全缺陷。可以是任意长度的应用代理链。注重，这个需求提到的是应用层代理，而不是AAA服务器链。例如，一个HTTP代理链可以每个都想要限制它们提供给“外界”的服务内容。当HTTPGET消息从HTTP代理到HTTP代理时，这个需求说明每个阶段做出的授权决定可依靠于浏览器用户，而不是说单单地依靠于前面HTTP代理特性。当然可以只包含唯一地一个AAA服务器，或包含很多。2.5.2虽然是应用代理链，每个阶段的AAA协议可以是独立的，也就是说第一跳使用推模式，第二跳使用拉模式，第三跳使用代理模式。这只是重复说明前面的需求(2.4.7)，明确它在使用应用代理的时候也可以应用。2.6信任模式2.6.1AAA实体必须能够根据授权信息的种类确认其它AAA实体是否可信。这和公钥基础结构中的需求是类似的：仅仅因为某人能产生一个加密的正确公钥证书，并不意味着应当信任它们的任何东西，尤其是，我可以因为某些目的信任这个发行者，但是对于其它的，则不一定信任。2.6.2AAA协议必须答应实体因为不同的目的而可信，信任不是一个要么全部信任要么全部不信任的问题。这联系起了打包(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.2AAA协议应当既支持事务授权，也支持会话连续授权。这说明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.6AAA协议应当答应一个AAA实体“取消”一个授权。期望AAA协议支持AAA实体能够发信号给一个应用或其它AAA实体，指出一个授权（可能是以前由一个第三方AAA实体授予的）不再有效。2.8治理2.8.1必须能够代表终坚固体和AAA实体治理授权数据。这个需求指出AAA的治理必须作为协议设计的部分考虑，一个要求所有AAA实体独立于所有其它AAA实体行动的AAA协议不满足要求。2.8.2应当支持所有特性的集中治理。应当可以做到（假如满足域的需求）集中或分布AAA的治理。2.8.3AAA协议应当支持用户（而不是治理员）有权批准一个事务。例如，一个用户可能想控制不吃午餐肉的方法或有权决定是否购买。在这种情况下，用户在某种程度说，是一个治理员。2.8.4一个AAA实体可以为另一个AAA实体创建授权规则。这是适当支持权利授予的需要，但是即便是答应，也必须以安全的方式完成。2.8.5当一个AAA实体链上的AAA实体维持一个会话失败的状态时，AAA协议应当支持故障恢复。例如，在网络访问情形下，可能需要一个已经崩溃的AAA服务器能够确定有多少个会话在处理，以便做出“下一个”授权决定。2.8.6一个AAA实体应当可以询问另一个AAA实体的授权状态。这是故障恢复过程的需要。2.8.7AAA协议必须能支持服务器组件的“热fail-over”而不丢失状态信息。这说明AAA协议必须能支持当一个服务器不再工作时，另一个服务器能自动“激活”而不丢失重要状态信息。2.9在线字节2.9.1需要时分离授权和验证，但是AAA协议必须答应单个消息既请求验证也请求授权。AAA协议必须答应授权和验证的分离，以便它们使用不同的机制。这说明有时需要在同一个消息中携带两类信息。2.9.2为了尽量减少资源的使用（例如，减少往返），必须能够把AAAPDU嵌入其它协议中。这说明必须定义AAA协议授权包，以便它们可以携带在其它协议中。例如，为了引用授权包而依靠AAA协议头信息可能使得协议不能满足需求。2.9.3AAA协议可以提供复制状态信息的机制。在要求热备份的情况下，需要这点支持系统恢复。注重，AAA协议当然从属于正规协议设计需求，也要求可靠性、没有单点故障等，即使这里没有全部指出。2.9.4AAA协议应当答应有可能在AAA协议和其它传统AAA相关协议之间实现网关功能。例如，很可能需要对RFC2138作为传统协议的某些形式的支持。当然，使用这样一个网关，在某种程度上总是意味着通过网关路由的事务没有满足某些需求（如，端到端的安全性）。这并不暗示说，这样的网关功能需要一台单独的服务器。2.9.5AAA协议必须能够支持使用大范围原语数据类型，包括RFC2277。例如，无疑总是需要传输不同长度、有符号和无符号的整数，可能还包含多精确度整数。可能还需要支持符合ANSIIEEE754-1985的浮点运算。2.9.6AAA协议传输应当支持优化主机对之间数据流里面小包的长期交换。典型地，NASes有大量地事务/秒，因此AAA协议必须答应控制请求流使得服务器能更有效地使用它的接受缓存。2.9.7AAA协议必须对提供负载均衡的支持。假如一个实体对不能接受任何最近的请求，那么AAA协议必须答应在实体对之间实现请求负载的均衡。2.10接口2.10.1应当可以使授权数据用于应用的目的。例如，在访问web时，假如授权数据包含一个组名、机制，使得应用可获得此数据，以便修改最初想要请求的URL。2.10.2应当可以使授权数据能用于调整一个请求的响应。例如，访问web时，清除属性值可能影响HTTP响应消息的内容。2.10.3AAA协议应当能够在请求者没有提前注册（至少是为了授权目的，但是也可以是为了验证目的）的情况下操作。这在衡量有多个请求者的AAA解决方案时是必要的。.2.10.4AAA协议必须能够支持授权和记账机制之间的连接。2.10.5AAA协议必须能够支持可记帐（审计/不可否认）机制。有时，一个授权决定在请求者尚未验证的情况下作出。在这种情况下，使用的授权数据必须和审计或其它责任机制相联系。注重：这个需求不要求必须支持数字签名或其它不可否认解决方案的某些部分。2.11协商2.11.1AAA协议必须支持访问授权包集合的能力，以便答应双方协商得到一个共同的集合。给定的双方可能支持不同的授权属性类型和包的组合，这个需求说明要求协议确保双方使用两方都支持的包。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.8AAA协议使用的协商机制不应当易于受到“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.,deBruijn,B.,deLaat,C.,Holdrege,M.andD.Spence,"AAAAuthorizationFramework",RFC2904,August2000.[RFC2026]Bradner,S.,"TheInternetStandardsProcess--Revision3",BCP9,RFC2026,October1996.[RFC2119]Bradner,S.,"KeyWordsforuseinRFCstoIndicateRequirementLevels",BCP14,RFC2119,March1997.[RFC2138]Rigney,C.,Rubens,A.,Simpson,W.andS.Willens,"RemoteAuthenticationDialInUserService(RADIUS)",RFC2138,April1997.[RFC2277]Alvestrand,H.,"IETFPolicyonCharacterSetsandLanguages",RFC2277,January1998.[SAMP]Vollbrecht,J.,Calhoun,P.,Farrell,S.,Gommans,L.,Gross,G.,deBruijn,B.,deLaat,C.,Holdrege,M.andD.Spence,"AAAAuthorizationApplicationExamples",RFC2905,August2000.作者的地址StephenFarrellBaltimoreTechnologies61/62FitzwilliamLaneDublin2,IRELANDPhone:+353-1-647-7300Fax:+353-1-647-7499EMail:stephen.farrell@baltimore.ieJohnR.VollbrechtInterlinkNetworks,Inc.775TechnologyDrive,Suite200AnnArbor,MI48108USAPhone:+17348211205Fax:+17348211235EMail:jrv@interlinknetworks.comPatR.CalhounNetworkandSecurityResearchCenter,SunLabsSunMicrosystems,Inc.15NetworkCircleMenloPark,California,94025USAPhone:+16507867733Fax:+16507866445EMail:pcalhoun@eng.sun.comLeonGommansEnterasysNetworksEMEAKerkplein242841XMMoordrechtTheNetherlandsPhone:+31182379279email:gommans@cabletron.comoratUniversityofUtrecht:l.h.m.gommans@phys.uu.nlGeorgeM.GrossLucentTechnologies184LibertyCornerRoad,m.s.LC2N-D13Warren,NJ07059USAPhone:+19085804589Fax:+1908-580-4991EMail:gmgross@lucent.comBettydeBruijnInterpayNederlandB.V.Eendrachtlaan3153526LBUtrechtTheNetherlandsPhone:+31302835104EMail:betty@euronet.nlCeesT.A.M.deLaatPhysicsandAstronomydept.UtrechtUniversityPincetonplein5,3584CCUtrechtNetherlandsPhone:+31302534585Phone:+31302537555EMail:delaat@phys.uu.nlMattHoldregeipVerse223XimenoAve.LongBeach,CA90803EMail:matt@ipverse.comDavidW.SpenceInterlinkNetworks,Inc.775TechnologyDrive,Suite200AnnArbor,MI48108USAPhone:+17348211203Fax:+17348211235EMail:dspence@interlinknetworks.com完整版权声明Copyright(C)TheInternetSociety(2000).AllRightsReserved.Thisdocumentandtranslationsofitmaybecopiedandfurnishedtoothers,andderivativeworksthatcommentonorotherwiseeXPlainitorassistinitsimplementationmaybeprepared,copied,publishedanddistributed,inwholeorinpart,withoutrestrictionofanykind,providedthattheabovecopyrightnoticeandthisparagraphareincludedonallsuchcopiesandderivativeworks.However,thisdocumentitselfmaynotbemodifiedinanyway,suchasbyremovingthecopyrightnoticeorreferencestotheInternetSocietyorotherInternetorganizations,exceptasneededforthepurposeofdevelopingInternetstandardsinwhichcasetheproceduresforcopyrightsdefinedintheInternetStandardsprocessmustbefollowed,orasrequiredtotranslateitintolanguagesotherthanEnglish.ThelimitedpermissionsgrantedaboveareperpetualandwillnotberevokedbytheInternetSocietyoritssuccessorsorassigns.Thisdocumentandtheinformationcontainedhereinisprovidedonan"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERINGTASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDINGBUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATIONHEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOFMERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.AcknowledgementFundingfortheRFCEditorfunctioniscurrentlyprovidedbytheInternetSociety.