rfc2096.txt

RFC文档

有效地使用它的接受缓存。
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: [phone]
   Fax: [phone]
   EMail: [e-mail]
   John R. Vollbrecht
   Interlink Networks, Inc.
   775 Technology Drive, Suite 200
   Ann Arbor, MI  48108
   USA
   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]
   Pat R. Calhoun
   Network and Security Research
   Center, Sun Labs
   Sun Microsystems, Inc.
   15 Network Circle
   Menlo Park, California, 94025
   USA
   Phone:  [phone]
   Fax:  [phone]
   EMail:  [e-mail]
   Leon Gommans
   Enterasys Networks EMEA
   Kerkplein 24
   2841 XM  Moordrecht
   The Netherlands
   Phone: [phone]
   email: [e-mail]
          or at University of Utrecht:
          [e-mail]
   George M. Gross
   Lucent Technologies
   184 Liberty Corner Road, m.s.
   LC2N-D13
   Warren, NJ 07059
   USA
   Phone:  [phone]
   Fax:    [phone]
   EMail:  [e-mail]
   Betty de Bruijn
   Interpay Nederland B.V.
   Eendrachtlaan 315
   3526 LB Utrecht
   The Netherlands
   Phone: [phone]
   EMail: [e-mail]
   Cees T.A.M. de Laat
   Physics and Astronomy dept.
   Utrecht University
   Pincetonplein 5,
   3584CC Utrecht
   Netherlands
   Phone: [phone]
   Phone: [phone]
   EMail: [e-mail]
   Matt Holdrege
   ipVerse
   223 Ximeno Ave.
   Long Beach, CA 90803
   EMail: [e-mail]
   David W. Spence
   Interlink Networks, Inc.
   775 Technology Drive, Suite 200
   Ann Arbor, MI  48108
   USA
   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]
完整版权声明
   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文档中文翻译计划