2.9.6 AAA協(xié)議傳輸應(yīng)當(dāng)支持優(yōu)化主機(jī)對(duì)之間數(shù)據(jù)流里面小包的長(zhǎng)期交換。
   典型地，NASes有大量地事務(wù)/秒，因此AAA協(xié)議必須允許控制請(qǐng)求流使得服務(wù)器能更
有效地使用它的接受緩存。
2.9.7 AAA協(xié)議必須對(duì)提供負(fù)載均衡的支持。
   如果一個(gè)實(shí)體對(duì)不能接受任何最近的請(qǐng)求，那么AAA協(xié)議必須允許在實(shí)體對(duì)之間實(shí)現(xiàn)
請(qǐng)求負(fù)載的均衡。
2.10 接口
2.10.1 應(yīng)當(dāng)可以使授權(quán)數(shù)據(jù)用于應(yīng)用的目的。
   例如，在訪問(wèn)web時(shí)，如果授權(quán)數(shù)據(jù)包含一個(gè)組名、機(jī)制，使得應(yīng)用可獲得此數(shù)據(jù)，以
便修改最初想要請(qǐng)求的URL。
2.10.2 應(yīng)當(dāng)可以使授權(quán)數(shù)據(jù)能用于調(diào)整一個(gè)請(qǐng)求的響應(yīng)。
   例如，訪問(wèn)web時(shí)，清除屬性值可能影響HTTP響應(yīng)消息的內(nèi)容。
2.10.3 AAA協(xié)議應(yīng)當(dāng)能夠在請(qǐng)求者沒(méi)有提前注冊(cè)（至少是為了授權(quán)目的，但是也可以是為
了驗(yàn)證目的）的情況下操作。
   這在衡量有多個(gè)請(qǐng)求者的AAA解決方案時(shí)是必要的。.
2.10.4 AAA協(xié)議必須能夠支持授權(quán)和記賬機(jī)制之間的連接。
2.10.5 AAA協(xié)議必須能夠支持可記帳（審計(jì)/不可否認(rèn)）機(jī)制。
   有時(shí)，一個(gè)授權(quán)決定在請(qǐng)求者尚未驗(yàn)證的情況下作出。在這種情況下，使用的授權(quán)數(shù)據(jù)
必須和審計(jì)或其它責(zé)任機(jī)制相聯(lián)系。注意：這個(gè)需求不要求必須支持?jǐn)?shù)字簽名或其它不可否
認(rèn)解決方案的某些部分。
2.11 協(xié)商
2.11.1 AAA協(xié)議必須支持訪問(wèn)授權(quán)包集合的能力，以便允許雙方協(xié)商得到一個(gè)共同的集合。 
   給定的雙方可能支持不同的授權(quán)屬性類(lèi)型和包的組合，這個(gè)需求說(shuō)明要求協(xié)議確保雙方
使用兩方都支持的包。
2.11.2 必須能夠協(xié)商兩個(gè)不直接通訊的AAA實(shí)體間的授權(quán)包。
   這說(shuō)明，例如在包含一個(gè)代理程序的情況下，目的AAA服務(wù)器可能仍然需要協(xié)商。
2.11.3 如果協(xié)商結(jié)果不能得出一個(gè)可接受的共同支持集合，那么訪問(wèn)必須被拒絕。
   例如，如果服務(wù)器不能理解請(qǐng)求者的屬性，那么就不能授予訪問(wèn)權(quán)限。
2.11.4 如果協(xié)商結(jié)果不能得出一個(gè)可接受的共同支持集合，那么應(yīng)當(dāng)產(chǎn)生一個(gè)錯(cuò)誤指示發(fā)送
給另外的AAA實(shí)體。
   如果協(xié)商失敗，那么經(jīng)常需要管理員進(jìn)行干預(yù)，并且應(yīng)當(dāng)提供支持的協(xié)議。
2.11.5 可以提前規(guī)定協(xié)商的結(jié)果，但是這種情況下，AAA協(xié)議必須包含對(duì)“協(xié)商結(jié)果”的
確認(rèn)。
   即使配置了雙方支持的包，這也必須在假設(shè)兩端配置相同前進(jìn)行確認(rèn)。
2.11.6 對(duì)于每一個(gè)使用AAA協(xié)議的應(yīng)用來(lái)說(shuō)，必須有一個(gè)“強(qiáng)制執(zhí)行”的、可互操作的授
權(quán)包IETF標(biāo)準(zhǔn)追蹤規(guī)范。
   這個(gè)需求保證通訊雙方能夠指望發(fā)現(xiàn)提供了至少一個(gè)IETF指定的可互操作的AAA協(xié)
議，它們完成對(duì)一個(gè)共同應(yīng)用的特殊問(wèn)題域的授權(quán)。這不排除對(duì)共同理解，但專(zhuān)用的AAA
協(xié)議授權(quán)包類(lèi)型（比方說(shuō)，廠商指定的細(xì)節(jié)）的協(xié)商。
2.11.7 還應(yīng)當(dāng)可以按照優(yōu)先權(quán)的順序?qū)AA協(xié)商選項(xiàng)進(jìn)行排列。
   這說(shuō)明，當(dāng)協(xié)商時(shí)，雙方必須能夠標(biāo)識(shí)優(yōu)先權(quán)以及性能。
2.11.8 AAA協(xié)議使用的協(xié)商機(jī)制不應(yīng)當(dāng)易于受到“bidding-down”攻擊。
   "bidding-down"攻擊是指攻擊者強(qiáng)迫協(xié)商雙方選擇可得到的“最弱”選項(xiàng)。這和在一個(gè)鏈
接上強(qiáng)迫40比特加密是類(lèi)似的。這個(gè)需求強(qiáng)調(diào)需要協(xié)議支持以阻值此類(lèi)攻擊，舉例來(lái)說(shuō)，
如果驗(yàn)證已經(jīng)產(chǎn)生了一個(gè)共享的密碼，那么可以把協(xié)商消息作為后面MAC計(jì)算的部分。
2.11.9 通訊雙方不能發(fā)送前面成功協(xié)商不同意的授權(quán)包和屬性類(lèi)。如果發(fā)生這樣的AAA協(xié)
議破壞，那么必須要給錯(cuò)誤行動(dòng)的對(duì)方發(fā)送錯(cuò)誤指示，并且給網(wǎng)絡(luò)操作者產(chǎn)生一個(gè)錯(cuò)誤指示。 
2.11.10 通訊雙方必須在初始化協(xié)商查詢包中公布所有它理解的授權(quán)包集合。
3. 需要考慮的安全問(wèn)題
   本文檔包含特定的安全需求。
   本文檔不聲明任何關(guān)于驗(yàn)證、記帳或可記帳性（審計(jì)）之間相互影響的詳細(xì)需求。 
   一個(gè)滿足所有以上這些需求的AAA協(xié)議，可能因?yàn)檫@樣的互操作而導(dǎo)致脆弱性。這些
問(wèn)題必須當(dāng)作AAA協(xié)議設(shè)計(jì)的一部分加以考慮。
4. 參考書(shū)目
   [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
完整版權(quán)聲明
   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授權(quán)要求
RFC文檔中文翻譯計(jì)劃                                                                      2