AAA 授權要求

本備注狀態
本備注為Internet社區提供信息，并不列入任何的Internet標準中。本備注的發行沒有限
制。
版權通告
Copyright(C)TheInternetSociety(2000).AllRightsReserved.
摘要
本文檔詳述了驗證授權記賬協議為支持Internet授權服務而必須滿足的需求。這些需求
是通過研究一系列應用得出的，包括移動IP，漫游操作（roamops，RoamingOperating）以
及其他應用。




目錄
1.介紹 2
2.需求 2
2.1授權信息 3
2.2授權信息的安全 4
2.3時間 5
2.4拓撲 6
2.5應用代理 7
3.需要考慮的安全問題 10
4.參考書目 10
作者的地址 11
完整版權聲明 12

1.介紹
本文檔是一系列三個文檔中的一個，這些文檔是AAAarchRG（AAAarchitectureResearch
Group）考慮用來處理AAA協議授權需求。這三個文檔是：
AAA授權框架——AAAAuthorizationFramework[FRMW]
AAA授權需求——AAAAuthorizationRequirements（本文檔）
AAA授權應用范例——AuthorizationApplicationExamples[SAMP]
本備注的工作是由原來的IETFAAA工作組授權分組完成的。當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協議必須支持非一致性信息
的使用，比如支持基于訪問控制的任務（rolebasedaclearcase/" target="_blank" >ccesscontrol，RBAC）。
要求支持基于許可、任務、組和其它信息的授權。只攜帶一致性信息的AAA協議將不
滿足需求。
2.1.6授權數據除了包含最終實體直接擁有的屬性外，可能還包含限制。
這說明某些屬性不是簡單地表示一個實體的屬性，例如IR1,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.12AAA協議必須指定更新規則的機制，這些規則是用來控制授權決定的。
這說明不能提供分布授權規則的AAA協議是不充分的。例如，這可用來下載ACLs到
PDP。
注意，這并不意味著必須總是使用此AAA協議機制，簡單地說就是它們必須在使用時
可獲得。特別的，在通常情況下會使用存儲在可信任庫（通常是LDAP服務器）里的授權
規則，而不是這樣的一個AAA協議機制。這個要求在兩種情況下都不要求授權規則有標準
格式，僅僅是有一個傳輸它們的機制。
2.1.13AAA協議必須允許AAA實體鏈包含在授權決定中。
這說明，多于一個的AAA服務器必須包含在單個授權決定中。這種情況的發生可能是
由于決定通過多個“域”傳播或是為了把授權分布在單個“域”中。
2.1.14AAA協議必須允許中間AAA實體可往AAA請求或響應中增加它們自己本地的授權
信息。
這說明，當有多個AAA實體包含在授權決定中時，每個AAA實體都可以通過增加更多
的信息或處理部分信息來實現對AAA消息的利用。
2.1.15AAA實體既可以單獨使用又可以和應用實體綜合。
這說明，AAA實體既可以作為AAA服務器實現，也可以和應用實體綜合。
2.1.16AAA協議必須支持規則的建立和編碼，這些規則在一臺基于另一個AAA服務器發布
的屬性的AAA服務器上激活。發出請求的AAA服務器的授權級別可以管理關于屬性的視
圖。
這說明，一個AAA實體必須可以把授權信息分布到另一個上，而且說明接收這個規則
的AAA實體可以只看作問題的部分。
2.1.17AAA協議必須支持關鍵和非關鍵屬性類。
這和在公鑰證書擴展中使用關鍵程度標志是類似的。
2.1.18AAA協議必須允許授權規則按照已評估的其它授權規則組合來表示。
例如，如果請求者是備份用戶組而不是管理員組的成員時才準許訪問。注意，這個要求
沒有說明支持何種類型的組合。
2.1.19應當可以基于請求者的地理位置、服務或AAA實體做出授權決定。
這僅是一個授權屬性類的例子，明顯是因為它要求不同的基礎實現機制。
2.1.20應當可以基于請求者、服務或AAA實體使用的身份或裝備做出授權決定。
這僅是一個授權屬性類的例子，明顯是因為它可能要求不同的基礎實現機制（如果不可
利用IPSec）。
2.1.21當一個給定的屬性有多個實例時，一定有個明確的機制使得接收對可決定指定實例的
值。
2.2授權信息的安全
2.2.1必須使授權信息可安全地在AAA和應用協議中通訊。必須指定機制保持信息的真實
性、完整性和保密性。
這說明必須有很好定義的方法保護授權信息的安全，但并不總是需要使用這樣的方法。
當然，是否支持為了一致性而要求的這些機制是開放的。特別的，必須提供機制禁止鏈中間
的服務管理員讀取或改變在另外兩個AAA實體間的授權信息。
2.2.2AAA協議必須允許使用授權信息的適當安全級別。AAA協議必須支持數據完整性/一
致性等的高安全機制和低安全機制。
重要的是AAA協議不要造成負擔太大的安全開銷，因而并不總需要使用指定的安全機
制（雖然不使用它們可能會影響授權決定）。
2.2.3安全要求可能根據授權信息包的不同部分而不同。
某些部分可能要求一致性和完整性，某些部分可能只要求完整性。這有力地說明了需要
類似選擇字段的安全機制。例如，獲得訪問一個網絡所需要的信息必須是明確的，有時訪問
網絡中一個應用所需的信息必須在AAA協議中加密。
2.2.4AAA協議必須提供機制來防止中間管理員破壞安全。
阻止中間人攻擊，比如中間管理員改變傳送中的AAA消息，這是個基本要求。
2.2.5AAA協議必不能打開基于重放授權信息的重放攻擊。
例如，AAA協議不應當允許擴散法攻擊，否則攻擊者重放AAA消息，而接收者需要使
用大量的CPU或通訊才能探測出重放。
2.2.6AAA協議必須能夠平衡任何實體對驗證機制，它們可能已經應用－這可提供額外的確
認，保證授權信息的擁有者和驗證實體是相同的。例如，如果IPSec提供了足夠證明，那么
就可以省略AAA協議驗證。
2.2.7授權信息包可能要求端到端的機密性、完整性、對等實體驗證或認可。
這說明必須為部分AAA消息提供機密性（resp.其它安全服務），即使是通過其它AAA
實體傳輸。當然允許這樣的AAA消息也可以包含非機密性（resp.其它安全服務）部分。另
外，中間的AAA實體認為自己在應用于AAA消息其余部分的端到端安全服務中是終結點。
2.2.8AAA協議即使在不需要驗證實體對的情況下（比如，在一個安全LAN中，網絡地址
就完全可以決定），也必須是可用的。
這個要求（在某種意義上和2.2.6相反）指明需要的靈活程度，以便使AAA協議可在很
廣泛的應用/服務范圍內使用。
2.2.9AAA協議必須為所有的協議選項指定“安全”缺省值。AAA實體的實現必須使用這
些“安全”缺省值，除非另外配置/管理。
這說明配置必須是“安全的”，例如，如果不配置AAA實體，那么授權決定應當拒絕訪
問。注意，對“安全”的解釋應當根據情況的不同而不同，雖然原則是相同的。
2.3時間
2.3.1授權信息必須是及時的，也就是說信息必須有期限，并且在某種情況下可以在期滿以
前撤銷。
這說明授權信息本身在任何時候都不認為是有效的，授權信息的每個部分必須與清楚的
或絕對的有效期或生存期相關聯。
2.3.2AAA協議必須提供在特定權限下，撤銷授權信息的機制。
雖然有效期或生命期較長，所以可能需要撤銷授權信息，例如當一個人離開公司時。注
意，這個需求并不指定一個特別的撤銷規劃，所以不需要黑名單或CRLs。
2.3.3一組屬性可以有一個關聯的有效期，使得這組屬性只能在此期間用來做授權決定。有
效期可以相對較長（例如，幾個月）或較短（幾個小時或幾分鐘）。
這說明有時需要明確的有效期字段。
2.3.4授權決定可能是對時間敏感的。必須有對諸如“工作時間”或等價概念的支持。
這說明AAA協議必須能夠支持時間控制屬性的傳輸，雖然并不要求AAA協議必須包含
一種表示“工作時間”類約束的標準方法。
2.3.5必須可以支持產生依賴于時間的結果的授權決定。
例如，授權結果可能是服務應當在一定時期內提供。在這時，AAA協議必須能夠傳輸這
個信息，可能是作為授權決定的指定結果，或者是作為附加的“服務終止”AAA消息以后
傳輸。
2.3.6必須支持授權信息在授權決定之前發布的模型，而不是在接近做出授權決定時。
這樣作是為了支持預付費（和預訂相反）情況（如，VoIP）。
2.3.7必須可以支持在服務請求之前做出授權決定的模型。
這是因為某些應用程序，如備份，它們的操作安排到了將來的日子。還包括那些需要預
留資源的應用。
2.3.8AAA機制必須允許授權信息攜帶時間戳信息（例如，用于不可否認服務）。
PKIXWG（Public-KeyInfrastructure(X.509)WG(pkix-wg)）正在開發時間戳協議，可作
為不可否認解決方案的一部分。在某些環境下，某些AAA協議消息必須帶有時間戳（由可
信任的權威加蓋時間戳）并且時間戳在隨后的AAA消息中轉發。
2.4拓撲
2.4.1AAA協議必須能夠支持使用推、拉和代理模式。
這說明只支持一個模式的協議，比如拉，不能滿足所有應用的需求。模式在[FRMW]中
定義。
2.4.2在包含多個AAA實體的事務/會話中，每一“跳”可以使用一個不同推/拉/代理模式。
例如，對于移動IP來說，一個“外來”AAA服務器可以從代理程序拉到授權信息，然
而代理程序可以把某些授權信息推到一個“本地”AAA服務器。
2.4.3AAA協議必須適用于那些應用和服務，它們包含在應用或AAA協議中的實體屬于不
同的（安全的）域。
這說明對于任何AAA協議消息必須可以跨安全或管理域邊界。典型的，當跨越這樣的
邊界時，使用高安全級別，并且記賬機制也必須更加嚴格。
2.4.4AAA協議必須支持漫游。
這里的漫游也可以被認為是“離開家”操作。例如，這是移動IP的基本需要。
2.4.5AAA協議應當支持動態移動性。
這里的動態移動是指，客戶端從一個域移至另一個域，而不需要完全重建，保留了所有
的AAA會話信息。
2.4.6授權決定必須可以在請求者和網絡有任何其它連接以前做出。
例如，這意味著請求者不可以在網絡中游走，隨意讀取東西，必須通過應用/服務或通過
中間AAA實體發出請求。AAA協議不應當將此服務器暴露給拒絕服務攻擊。
2.4.7AAA必須支持使用中間AAA實體，它們參與授權事務，但是并不“擁有”任何最終
實體或授權數據。
在某些環境中（如漫游操作），這些實體稱為代理（雖然它們和QoS環境中的帶寬代理
不相同）。
2.4.8AAA協議可支持中間AAA實體返回一個轉發地址給請求者或AAA實體的情況，使得
請求者或發起AAA實體可以和其它AAA實體聯系。
這個需求考慮AAA服務器會有路由問題，并且要求AAA協議能夠避免這樣的路由。例
如，對于移動IP，需要一個代理，使得部分地允許外地和本地AAA服務器獲得聯系。
2.4.9對于訪問決定功能必須可以發現請求者的AAA服務器。如果請求者提供用于發現過
程的信息，然后訪問決定功能必須能夠驗證此信息是可信的。
這說明不僅AAA服務器必須能夠互相發現，而且有時一個應用實體也必須發現一個適
當的AAA服務器。
2.5應用代理
2.5.1AAA協議必須支持應用使用代理，也就是說，應用實體(C)產生一個服務請求，發到
對端(I)，并且這個中間(I)也發出一個代表客戶(C)的服務請求，發往最終目標(T)。AAA協議
必須在T做出授權決定，依賴于C和/或I關聯的授權信息。這個“應用代理”不能夠往AAA
協議中引入新的安全缺陷?？梢允侨我忾L度的應用代理鏈。
注意，這個需求提到的是應用層代理，而不是AAA服務器鏈。例如，一個HTTP代理
鏈可以每個都想要限制它們提供給“外界”的服務內容。當HTTPGET消息從HTTP代理
到HTTP代理時，這個需求說明每個階段做出的授權決定可依賴于瀏覽器用戶，而不是說單
單地依賴于前面HTTP代理特性。當然可以只包含唯一地一個AAA服務器，或包含很多。
2.5.2雖然是應用代理鏈，每個階段的AAA協議可以是獨立的，也就是說第一跳使用推模
式，第二跳使用拉模式，第三跳使用代理模式。
這只是重復說明前面的需求(2.4.7)，明確它在使用應用代理的時候也可以應用。
2.6信任模式
2.6.1AAA實體必須能夠根據授權信息的種類確認其它AAA實體是否可信。
這和公鑰基礎結構中的需求是類似的：
僅僅因為某人能產生一個加密的正確公鑰證書，并不意味著應當信任它們的任何東西，
尤其是，我可以因為某些目的信任這個發行者，但是對于其它的，則不一定信任。
2.6.2AAA協議必須允許實體因為不同的目的而可信，信任不是一個要么全部信任要么全部
不信任的問題。
這聯系起了打包(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.2AAA協議應當既支持事務授權，也支持會話連續授權。
這說明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.6AAA協議應當允許一個AAA實體“取消”一個授權。
期望AAA協議支持AAA實體能夠發信號給一個應用或其它AAA實體，指出一個授權
（可能是以前由一個第三方AAA實體授予的）不再有效。
2.8管理
2.8.1必須能夠代表終結實體和AAA實體管理授權數據。
這個需求指出AAA的管理必須作為協議設計的部分考慮，一個要求所有AAA實體獨立
于所有其它AAA實體行動的AAA協議不滿足要求。
2.8.2應當支持所有特性的集中管理。
應當可以做到（如果滿足域的需求）集中或分布AAA的管理。
2.8.3AAA協議應當支持用戶（而不是管理員）有權批準一個事務。
例如，一個用戶可能想控制不吃午餐肉的方法或有權決定是否購買。在這種情況下，用
戶在某種程度說，是一個管理員。
2.8.4一個AAA實體可以為另一個AAA實體創建授權規則。
這是適當支持權利授予的需要，但是即便是允許，也必須以安全的方式完成。
2.8.5當一個AAA實體鏈上的AAA實體維持一個會話失敗的狀態時，AAA協議應當支持
故障恢復。
例如，在網絡訪問情形下，可能需要一個已經崩潰的AAA服務器能夠確定有多少個會
話在處理，以便做出“下一個”授權決定。
2.8.6一個AAA實體應當可以詢問另一個AAA實體的授權狀態。
這是故障恢復過程的需要。
2.8.7AAA協議必須能支持服務器組件的“熱fail-over”而不丟失狀態信息。
這說明AAA協議必須能支持當一個服務器不再工作時，另一個服務器能自動“激活”
而不丟失重要狀態信息。
2.9在線字節
2.9.1需要時分離授權和驗證，但是AAA協議必須允許單個消息既請求驗證也請求授權。
AAA協議必須允許授權和驗證的分離，以便它們使用不同的機制。這說明有時需要在同
一個消息中攜帶兩類信息。
2.9.2為了盡量減少資源的使用（例如，減少往返），必須能夠把AAAPDU嵌入其它協議中。
這說明必須定義AAA協議授權包，以便它們可以攜帶在其它協議中。例如，為了引用
授權包而依靠AAA協議頭信息可能使得協議不能滿足需求。
2.9.3AAA協議可以提供復制狀態信息的機制。
在要求熱備份的情況下，需要這點支持系統恢復。注意，AAA協議當然從屬于正規協議
設計需求，也要求可靠性、沒有單點故障等，即使這里沒有全部指出。
2.9.4AAA協議應當允許有可能在AAA協議和其它傳統AAA相關協議之間實現網關功能。
例如，很可能需要對RFC2138作為傳統協議的某些形式的支持。當然，使用這樣一個網
關，在某種程度上總是意味著通過網關路由的事務沒有滿足某些需求（如，端到端的安全性）。
這并不暗示說，這樣的網關功能需要一臺單獨的服務器。
2.9.5AAA協議必須能夠支持使用大范圍原語數據類型，包括RFC2277。
例如，無疑總是需要傳輸不同長度、有符號和無符號的整數，可能還包含多精確度整數。
可能還需要支持符合ANSIIEEE754-1985的浮點運算。
2.9.6AAA協議傳輸應當支持優化主機對之間數據流里面小包的長期交換。
典型地，NASes有大量地事務/秒，因此AAA協議必須允許控制請求流使得服務器能更
有效地使用它的接受緩存。
2.9.7AAA協議必須對提供負載均衡的支持。
如果一個實體對不能接受任何最近的請求，那么AAA協議必須允許在實體對之間實現
請求負載的均衡。
2.10接口
2.10.1應當可以使授權數據用于應用的目的。
例如，在訪問web時，如果授權數據包含一個組名、機制，使得應用可獲得此數據，以
便修改最初想要請求的URL。
2.10.2應當可以使授權數據能用于調整一個請求的響應。
例如，訪問web時，清除屬性值可能影響HTTP響應消息的內容。
2.10.3AAA協議應當能夠在請求者沒有提前注冊（至少是為了授權目的，但是也可以是為
了驗證目的）的情況下操作。
這在衡量有多個請求者的AAA解決方案時是必要的。.
2.10.4AAA協議必須能夠支持授權和記賬機制之間的連接。
2.10.5AAA協議必須能夠支持可記帳（審計/不可否認）機制。
有時，一個授權決定在請求者尚未驗證的情況下作出。在這種情況下，使用的授權數據
必須和審計或其它責任機制相聯系。注意：這個需求不要求必須支持數字簽名或其它不可否
認解決方案的某些部分。
2.11協商
2.11.1AAA協議必須支持訪問授權包集合的能力，以便允許雙方協商得到一個共同的集合。
給定的雙方可能支持不同的授權屬性類型和包的組合，這個需求說明要求協議確保雙方
使用兩方都支持的包。
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.8AAA協議使用的協商機制不應當易于受到“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.,deBruijn,B.,
deLaat,C.,Holdrege,M.andD.Spence,"AAAAuthorizationFramework",RFC2904,August
2000.
[RFC2026]Bradner,S.,"TheInternetStandardsProcess--Revision3",BCP9,RFC2026,
October1996.
[RFC2119]Bradner,S.,"KeywordsforuseinRFCstoIndicateRequirementLevels",BCP
14,RFC2119,March1997.
[RFC2138]Rigney,C.,Rubens,A.,Simpson,W.andS.Willens,"RemoteAuthentication
DialInUserService(RADIUS)",RFC2138,April1997.
[RFC2277]Alvestrand,H.,"IETFPolicyonCharacterSetsandLanguages",RFC2277,
January1998.
[SAMP]Vollbrecht,J.,Calhoun,P.,Farrell,S.,Gommans,L.,Gross,G.,deBruijn,B.,
deLaat,C.,Holdrege,M.andD.Spence,"AAAAuthorizationApplicationExamples",RFC2905,
August2000.
作者的地址
StephenFarrell
BaltimoreTechnologies
61/62FitzwilliamLane
Dublin2,
IRELAND
Phone:+353-1-647-7300
Fax:+353-1-647-7499
EMail:stephen.farrell@baltimore.ie
JohnR.Vollbrecht
InterlinkNetworks,Inc.
775TechnologyDrive,Suite200
AnnArbor,MI48108
USA
Phone:+17348211205
Fax:+17348211235
EMail:jrv@interlinknetworks.com
PatR.Calhoun
NetworkandSecurityResearch
Center,SunLabs
SunMicrosystems,Inc.
15NetworkCircle
MenloPark,California,94025
USA
Phone:+16507867733
Fax:+16507866445
EMail:pcalhoun@eng.sun.com
LeonGommans
EnterasysNetworksEMEA
Kerkplein24
2841XMMoordrecht
TheNetherlands
Phone:+31182379279
email:gommans@cabletron.com
oratUniversityofUtrecht:
l.h.m.gommans@phys.uu.nl
GeorgeM.Gross
LucentTechnologies
184LibertyCornerRoad,m.s.
LC2N-D13
Warren,NJ07059
USA
Phone:+19085804589
Fax:+1908-580-4991
EMail:gmgross@lucent.com
BettydeBruijn
InterpayNederlandB.V.
Eendrachtlaan315
3526LBUtrecht
TheNetherlands
Phone:+31302835104
EMail:betty@euronet.nl
CeesT.A.M.deLaat
PhysicsandAstronomydept.
UtrechtUniversity
Pincetonplein5,
3584CCUtrecht
Netherlands
Phone:+31302534585
Phone:+31302537555
EMail:delaat@phys.uu.nl
MattHoldrege
ipVerse
223XimenoAve.
LongBeach,CA90803
EMail:matt@ipverse.com
DavidW.Spence
InterlinkNetworks,Inc.
775TechnologyDrive,Suite200
AnnArbor,MI48108
USA
Phone:+17348211203
Fax:+17348211235
EMail:dspence@interlinknetworks.com
完整版權聲明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.
Thisdocumentandtranslationsofitmaybecopiedandfurnishedtoothers,andderivative
worksthatcommentonorotherwiseexplainitorassistinitsimplementationmaybeprepared,
copied,publishedanddistributed,inwholeorinpart,withoutrestrictionofanykind,provided
thattheabovecopyrightnoticeandthisparagraphareincludedonallsuchcopiesandderivative
works.However,thisdocumentitselfmaynotbemodifiedinanyway,suchasbyremovingthe
copyrightnoticeorreferencestotheInternetSocietyorotherInternetorganizations,exceptas
neededforthepurposeofdevelopingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbefollowed,orasrequiredtotranslateit
intolanguagesotherthanEnglish.
ThelimitedpermissionsgrantedaboveareperpetualandwillnotberevokedbytheInternet
Societyoritssuccessorsorassigns.
Thisdocumentandtheinformationcontainedhereinisprovidedonan"ASIS"basisandTHE
INTERNETSOCIETYANDTHEINTERNETENGINEERINGTASKFORCEDISCLAIMS
ALLWARRANTIES,EXPRESSORIMPLIED,INCLUDINGBUTNOTLIMITEDTOANY
WARRANTYTHATTHEUSEOFTHEINFORMATIONHEREINWILLNOTINFRINGE
ANYRIGHTSORANYIMPLIEDWARRANTIESOFMERCHANTABILITYORFITNESS
FORAPARTICULARPURPOSE.
Acknowledgement
FundingfortheRFCEditorfunctioniscurrentlyprovidedbytheInternetSociety.