rfc2096.txt

RFC文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
译者：郭立群（guoliqun    [e-mail]）
译文发布时间：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或通讯才能探测出重放。