rfc2096.txt

RFC文档

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协议必须允许控制请求流使得服务器能更