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協議必須允許控制請求流使得服務器能更