組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
譯者：郭立群（guoliqun    guoliqun@sina.com）
譯文發布時間：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或通訊才能探測出重放。