1、 PAGE15 / NUMPAGES15第一章引言研究背景和方向近幾年來，隨著Internet 的迅猛發展，用戶接入網絡數不斷增加，ISP（InternetService Provider 服務提供商）對用戶接入和計費管理變得日益重要。在其它領域，如IP 運營商、大規模防火墻等，對用戶接入認證的要求也越來越高，原有的簡單認證方式已經不滿足當前需要，迫切需要一種能夠完成實時用戶接入認證、實時記賬、全局漫游、多種計費方式、支持多種認證安全方式、跨越多平臺的用戶接入認證系統。RADIUS（Remote Authentication Dial-In User Service 用戶遠程撥號驗證服務）協議

2、1作為IETF（Internet Engine Tasks Force 互聯網工程任務組）定義的標準協議已經越來越被大多數ISP、ITSP 和安全系統所認可。RADIUS 協議中所規定的接入認證（Authentication）、用戶授權（Authorization）、記賬（Accounting）2、漫游（Roaming）和屬性（Attribute）擴展方式等解決了眾多ISP 所面臨的問題，成為今后流行的趨勢。這樣，開發符合RADIUS 協議的用戶接入認證、授權和記賬的軟件成為構筑ISP、電信運營商、安全網絡系統中的必要部分?，F行的RADIUS 開發雖然部分滿足了用戶的需求，但存在幾個關鍵問題，

3、如開發者不能利用已有存在的系統，重復勞動，開發周期長；各種系統實現方式差異很大，不利于維護擴充；軟件特定平臺，不能跨越平臺使用；對協議包理解方式不同，不能互通漫游等，這樣就需要一種全新的開發方法和框架。我們分析了國際上流行的各種RADIUS 系統實現，依照最新的協議與討論草案，結合其它系統的先進優點，設計并實現了一個可擴充的AAA 協議棧軟件包。根據這個軟件包，用戶可以在協議棧的基礎之上，選擇自己所需要的運行模塊和連接方式，編寫符合自己需要的用戶回調函數和全局設置接口，就可以完成一個標準的RADIUS系統。用戶使用本協議棧開發RADIUS 系統時，可以脫離編寫協議時的各種繁瑣過程，無需考慮協議

4、的語法和數據包的結構，并且使系統所覆蓋的協議最多。采用這種方法開發的RADIUS 系統具有符合國際標準協議、使用簡便、開發周期短、系統靈活性高、易于擴充和與系統間可互通漫游的特點。我們采用這種方法已被開發者實際利用，產生極大的利用價值，具有很好的發展前景。在本文中，首先介紹RADIUS 協議與其特性，然后給出所設計協議棧的框架原理與其實現，協議棧所支持的功能和應用方法，最后給出結論和進一步需要完成的工一個可擴展的AAA 協議棧2作。相關工作國際上有一個組織和我們工作類似，項目名稱為“Stacks of InternetTelephony”3，開始時間大約為2000 年6 月。以下是我們所開發的

5、RADIUS 協議棧和這個項目中的關于RADIUS 的棧的比較：系統實現和功能本協議棧 Vovida 項目組繼承系統 Livingston RADIUS Merit AAA系統框架進程池單請求派生進程驗證方式 PAP、CHAP、MS-CHAP PAP、CHAP、MS-CHAP網管接口函數支持不支持用戶數據本地文件、數據庫只支持本地文件配置管理本地文件、數據庫只支持本地文件日志按時間遞進、數據庫簡單文本其它部分提供客戶端和測試程序無客戶端和測試程序第二章 RADIUS 相關協議與其特性RADIUS 系統框架遠程撥號用戶鑒別服務RADIUS 是朗訊網際互連系統中的一個基于客戶端/服務員的安全協議。

6、在RFC21384和RFC21395中被IETF 定義為標準協議。用戶相關信息存儲于一個中心位置，被稱為RADIUS 服務員。RADIUS 客戶端與RADIUS 服務員通過通信來驗證用戶。服務員返回給客戶端關于驗證用戶的操作權限。雖然RADIUS 這個名詞用來說明客戶端與服務員進行通信的網絡協議，但它經常被用來說明整個客戶端/服務員系統。如圖2-1 所示。一個可擴展的AAA 協議棧3RADIUS客戶端RADIUS服務員認證記賬請求認證記賬響應圖2-1：一個簡單的RADIUS 客戶端/服務員系統框架基于RADIUS 的遠程接入環境共包括三個部分：用戶、遠程接入服務員和RADIUS 服務員。每個用

7、戶是RAS 的一個客戶，而每個RAS 是用戶的服務員和RADIUS 服務員的客戶。結構如圖2-2。數據庫本地RADIUS服務員遠端RADIUS服務員RASISDNRASMODEMSRASFIREWALLRAS需認證端網絡計算機移動用戶Internet用戶請求接入者本地認證方法UNIX passwordWinNT DomainText圖2-2：一個RADIUS 服務員結構說明RAS 設備將不同連接用戶的請求轉換為RADIUS 認證請求或記賬請求。RADIUS 服務員可以接收來自不同RAS 設備上的請求信息，并選擇預先設定的認證方法來完成請求，并發送響應給RAS。處于不同位置的RADIUS 服務員

8、還可以連接在一起，組成一個RADIUS 認證環境。每個RADIUS 可以將發給自己的請求轉發給其它RADIUS 服務員來處理。結構如圖2-3。一個可擴展的AAA 協議棧4RADIUS服務員負責區域A用戶RADIUS服務員負責區域B用戶RADIUS服務員負責區域C用戶區域CRADIUS客戶端圖2-3：多個RADIUS 服務員的認證框架這樣就可以組成一個跨越不同地理位置的分布式認證環境，無論從認證用戶數量上，還是在用戶分布上都可以實現透明的集中式管理。RADIUS 基本功能RADIUS 是一個在用戶網絡接入設備（例如撥號服務器）和用戶信息存放設備之間交換信息的標準方法。它有三個基本功能。驗證（Au

9、thentication）：RADIUS 判別一個用戶請求服務是否合法。用戶鑒別信息可以存放在本地users 文件，本地數據庫、外部數據庫中；也可以通過其它驗證方式進行鑒別如UNIX 口令文件、Windows NT 域數據庫等。一個簡單的典型例子如下：一個撥號用戶通過RADIUS 協議試圖接入網絡的過程如下：1、用戶撥號進入一個遠程接入服務員（MODEM池）并開始一個PPP 會話；2、遠程接入服務員把從PPP 會話中得到的用戶驗證信息經過處理，打成RADIUS 協議請求包，傳送給RADIUS 服務員；3、如果RADIUS 服務員通過了這個驗證，它將發送接受響應給RAS，并附加上其它信息包括用戶

10、建立連接所需要的IP 地址、最接時間等等；如果RADIUS 不能驗證這個請求或驗證沒有通過，它將發送拒絕響應給RAS 以與錯誤的原因；4、使用這些信息，RAS 如果受到接受響應包，則它允許用戶開始操作網絡，如果拒絕則斷掉連接并給出錯誤信息。授權（Authorization）：RADIUS 協議可以控制用戶會話中使用特定的網絡設備服務。在RAS 發送的驗證請求信息中，除基本信息外，還可以有用戶期望連接類型等，RADIUS 服務員可以根據請求完成驗證。RADIUS 服務員可以將驗證通過的其它參數發送給RAS 以規定用戶連接。所有的屬性交換由用戶配置文件控制。配置文件中包括兩種屬性：檢查屬性和返回屬

11、性。檢查屬性定義了一些連接所需請求。RAS在向RADIUS 服務員發送驗證請求時必須具備這些屬性，否則驗證不會成功。返回一個可擴展的AAA 協議棧5屬性為驗證成功后RADIUS 服務員發送給RAS 的附加信息，例如定義連接的一些參數。一旦用戶通過認證，RADIUS 服務員根據系統預先設置的用戶配置文件，附加用戶可以使用的資源能力，如IP 地址、連接協議、連接速率等。通過這種方式，可以集中管理用戶的不同訪問能力，比如用戶普通撥號接入網絡時應該獲取的速率和連接方式和通過ISDN 撥入網絡的速率和連接方式，以與兩種方式的口令可以是不同的。記賬（Accounting）：RADIUS 協議可以記錄會話開

12、始記錄、會話結束記錄。包括本次連接的用戶名、開始連接時間、結束連接時間、用戶使用協議、用戶使用帶寬、傳輸數據量、連接斷開原因和出錯信息等。RADIUS 客戶端在連接開始的時候向RADIUS 服務員發送會話開始記錄，在連接結束的時候發送會話結束記錄。通常情況下RADIUS 服務員只記錄會話結束記錄；對于會話開始記錄一般用于用戶超時監測和切斷控制。RADIUS 擴充功能RADIUS 協議除了基本功能以外，為了適應Internet 的不斷擴大，增強了幾個功能：代理（漫游）：為了能夠使用戶能在異地通過認證使用服務，RADIUS 協議支持服務員之間轉發代理請求和響應。請求和響應的轉發根據RADIUS 服

13、務員存放在本地的proxy 文件或數據庫中存放的外部RADIUS 服務員信息進行。如圖2-3，當一個用戶在C 地要求使用服務時，C 地RADIUS 服務員首先判斷該用戶是否是本地用戶，如果不是，根據用戶特征查找代理表，看是否和用戶開戶地RADIUS A 有代理關系，如果有那么就轉發該請求到A地RADIUS 服務員，A地RADIUS 服務員完成驗證后，將響應結果發回C 地RADIUS 服務員，C 地RADIUS 再將結果發回給用戶。記賬簽名和時間戳：記賬請求/響應包必須簽名。根據包的容，使用客戶端與服務員之間的共享密鑰，通過MD5 算法計算包的摘要，這樣保證了記賬包不被竊聽者篡改。時間戳也保證了

14、記賬記錄的唯一性，保證記錄的準確性，防止竊聽者破環。用戶自定義屬性：RADIUS 協議除了規定的屬性外，用戶可以自行添加所需要的屬性。在添加用戶自定義屬性時，需要注明用戶ID 等標志。這樣不同運營商之間除了協議規定的屬性外，還可以互通其它屬性，交換信息。地址綁定：RADIUS 協議規定可以將RADIUS 服務員與指定的IP 地址綁定，這樣可以在多宿主主機上使用RADIUS。RADIUS 配置RADIUS 配置主要在RADIUS 服務員部分，通過各種配置文件進行。RADIUS 服務一個可擴展的AAA 協議棧6員所需要的配置文件全部放在名為 raddb 的目錄下。它的組織形式如下：圖2-4 RAD

15、IUS 目錄結構字典文件 dictionary：RADIUS 服務員使用字典文件來建立檢查屬性列表和返回屬性列表。字典文件包括可能用到的屬性名稱、屬性號、屬性值等。用戶文件users：存儲用戶的配置信息，包括鑒別和授權信息?？蛻粑募lients：存儲RADIUS 所有的本服務員對應的客戶端地址與共享密鑰。代理文件proxy：存儲所有遠程RADIUS 服務員的地址和共享密鑰等。菜單文件menus：存儲各種用戶通過認證后可以選擇的服務類型。RADIUS 特性基于RADIUS 協議的接入認證/計費系統提供以下特性：客戶機/服務員模式：要求對用戶進行認證的設備被稱為客戶端，要求RADIUS服務員進行

16、服務，而一個RADIUS 服務員也可以是其它服務員的客戶端。安全：在大型網絡中，安全信息分散于網絡不同設備上。RADIUS 協議可以允許用戶信息保存于一臺主機之上，最小化安全漏洞的危險。RADIUS 服務員管理所有鑒別和接入網絡服務的功能。RADIUS 服務員與客戶端之間使用共享密鑰進行通信。可適應性：RADIUS 軟件可以安裝在任何通信環境之中。也可以和其它安全系統和協議融合為一體。對用戶可以使用多種驗證方法。可擴展性：所有傳輸的信息被組織為稱為三元組（屬性、長度、值）中，新的屬性可以隨時添加。管理簡便：RADIUS 服務員將安全信息存儲于中心位置，只需要維護這一處信息即可。對不同廠商的遠程

17、接入設備可以按統一的安全模式維護和管理。廣泛的審計能力：RADIUS 提供一種審計跟蹤能力，稱為RADIUS 記賬。收集來的信息可以用來分析安全效果和計費。一個可擴展的AAA 協議棧7第三章協議?？蚣軈f議棧包含協議框架本協議棧所覆蓋的協議主要有以下幾個。1、 RADIUS 協議：定義于RFC2138 中，是RADIUS 體系的主要部分，主要對驗證和授權、包格式、語法和漫游等進行了規定。2、 RADIUS Accouting 協議：定義于RFC2139 中，主要對記賬、記賬包格式等進行了規定。3、 RADIUS Authentication Client MIB：定義于RFC26186中，主要定

18、義了用戶在RADIUS 認證客戶端中SNMP 代理需要的管理信息庫。4、 RADIUS Authentication Server MIB：定義于RFC26197中，主要定義了用戶在RADIUS 認證服務員中SNMP 代理需要的管理信息庫。5、 RADIUS Accounting Client MIB：定義于RFC26208中，主要定義了用戶在RADIUS 記賬客戶端中SNMP 代理需要的管理信息庫。6、 RADIUS Accounting Server MIB：定義于RFC26219中_，主要定義了用戶在RADIUS 記賬服務員中SNMP 代理需要的管理信息庫。本協議棧以TCP/IP 協議為

19、基礎，使用UDP 為主要傳輸手段。協議棧的核心為RFC2138 和RFC2139 組成的RADIUS 主要系統。RFC2618-RFC2621 主要實現協議棧具有網絡管理功能，示意圖如下。協議棧系統軟件包RFC2618 RFC2619 RFC2620 RFC2621RFC2138 Authentication RFC2139 AccountingUDPIP框圖3-1 協議棧包含的協議協議棧功能框架本協議棧的功能框架如圖3-2 所示。一個可擴展的AAA 協議棧8AAA協議棧包處理回調函數、用戶全局設置、接口函數網管模塊端口綁定監聽數據庫訪問模塊多種驗證方式包加密解密包接收發送漫游代理配置管理圖3

20、-2 RADIUS 協議棧功能框架各部分主要功能如下：配置管理：負責從本地配置文件或數據庫中讀取系統的參數設置，包括地址、端口號、認證協議、超時控制時間等。多種驗證方式：負責根據預先配置的方式對請求進行認證，包括PAP、CHAP、MS-CHAP 方式等。包加密解密：對認證請求包的口令字段進行加密和解密，生成所需的請求和響應驗證字。包接收發送：接收請求包，并將其組織成結構體形式；把結構體形式的數據結構打成二進制包。漫游代理：根據請求包容，應用設置條件，判斷其是否需要代理。如果需要代理，則處理后轉發出去。接收代理響應，并轉發給RADIUS 客戶端。端口綁定監聽：根據配置主機和端口信息，申請sock

21、et 并綁定于指定端口。監聽來自客戶端以與其它RADIUS 服務員的請求和響應。網管模塊：對RADIUS 系統的各個狀態和參數進行監控，并在SNMP 代理調用時將這些參數返回給調用者。數據庫訪問模塊：在對用戶認證和記賬時訪問用戶數據，訪問方式可以支持多種數據庫形式。包處理回調函數、用戶全局設置、接口函數：是用戶使用本協議棧時需要編寫的代碼部分，具體使用方法見第五章。第四章協議棧實現開發環境與工具一個可擴展的AAA 協議棧9本協議棧的開發環境有多種，可以是 WinNT，Linux，HP-UX，Solaris 等UNIX操作系統。如果使用專用數據庫的話，還需要在所用操作系統上安裝ORACLE 等數

22、據庫服務器與客戶端。工具是UNIX 上的C 編譯系統或者是WINDOWS 上的VC 編譯系統。本協議棧采用標準ANSI C 語言編寫，因為C 語言執行速度快，兼容性和跨平臺性好。系統邏輯流程使用本協議棧開發的RADIUS 服務員系統在處理請求包時采用的算法如圖4-1所示。打開預先定義端口或知名端口，申請網絡數據報套接字綁定到端口上，便于以后主動監聽。預先創建若干RADIUS子進程，并建立父子間通信的全雙工管道等待處理主進程發送給它們的處理請求。主進程讀取RADIUS代理表和RADIUS客戶端表，以后檢驗客戶端合法性和查找遠端代理地址。將網絡套接字和管道描述符全部放入一個SELECT描述字段中，

23、該字段中的項對應可以進行I/O的描述符。通過監控這個字段可以獲知那個I/O端口上有數據達到。求出包括網絡套接字和父子進程間管道描述字的最大值。SELECT監聽I/O。一旦數據到達，進行一下處理如果表中網絡套接字有數據發到，則調用處理子程序，該子程序首先判斷該請求的源是否合法，是否需要漫游處理，然后選擇預先分配的一個空閑進程處理請求。如果管道描述字有數據發到，則表示對應子進程處理請求完畢，子程序恢復空閑狀態。圖4-1 系統網絡通信算法一個可擴展的AAA 協議棧10使用本協議棧開發的RADIUS 服務員系統的系統邏輯流程如下。初始化配置（是否派生子進程、字典文件和日志文件路徑、終端參數）登記各種信

24、號處理例程s i g n a l ( )讀取配置文件r a d c o n f i g _ i n i t ( ) ，讀入主機地址、端口號、最大請求個數、代理服務超時時間、最大請求超時時間）讀取字典文件d i c t _ i n i t ( ) ，將字典容放入存組織成為鏈表，以后使用派生后臺進程f o r k ( ) ，退出當前會話，這樣脫離命令行關閉終端c l o s e ( ) ，顯示軟件版本打開知名端口o p e n _ u d p s o c k ( ) 綁定端口清空所有網絡套接字端口F D _ C L E A R ( ) ，準備監聽派生指定個數的子進程c h i l d _ m a

25、k e ( ) ，并監控父子進程間通信的讀寫管道申請表空間，調用T U X E D O ，讀取客戶端列表和代理服務員列表放入存表中u p d a t e _ c l i e n t s ( ) u p d a t e _ p r o x y ( )將監控描述符字段清零并置位F D _ Z E R O ( )循環非阻塞監控以上端口S E L E C T ( ) ，根據情況分別執行以下子程序F D _ I S S E T ( )認證記賬端口請求，調用認證處理r a d _ r e q u e s t ( ) 代理認證記賬端口請求，調用代理處理R a d _ p r o x y ( ) 子進程發送信

26、號，處理子進程完畢。子進程空閑置位。圖4-2 系統邏輯流程一個可擴展的AAA 協議棧11RADIUS 服務員中采用基于數據報的并發無連接網絡通信算法、進程處理采用主進程循環處理，子進程順序處理算法。并且為提高效率，采用進程預分配的方法。系統運行時，由空閑子進程組成一個空閑進程池，當有請求時，主進程順序選擇一個空閑子進程完成請求。子進程完成請求后通知父進程。示意見圖4-3。RADIUS主進程子進程池空閑子進程接收新請求的子進程正在處理請求的子進程完成子進程通知父親圖4-3 系統運行時進程關系圖包處理邏輯流程協議棧中的主進程在處理請求包時所作處理如圖4-4 所示。接收數據包到緩沖區 r e c v

27、 f r o m ( )判斷包源客戶端的合法性如果是認證包系列用f i n d _ c l i e n t ( )如果是記賬包系列用c a l c _ a c c t r e q ( )將緩沖區打成請求頭結構r a d r e c v ( )判斷是否需要代理h a n d l e _ p r o x y ( )需要代理，調用代理模塊保存漫游狀態p u s h _ p r o x y ( )發送到遠端s e n d p r o x y 2 s e r v e r ( )不需要代理，判斷是否是重包查找空閑子進程登記包特性到子進程結構中將請求包放入緩沖區通過F I F O 發送給子進程圖4-4 主進

28、程處理請求包流程一個可擴展的AAA 協議棧12協議棧中對于代理漫游包的處理如圖4-5 所示。接收數據包到緩沖區recvfrom()判斷包源服務員的合法性find_server()將緩沖區打成請求頭結構radrecv()找出包對應的描述符查找發送時記的請求頭pop_proxy()轉發響應給最初的客戶端sendproxy2client()圖4-5 漫游請求包流程協議棧中子進程處理請求包的流程圖如圖4-6 所示。循環等待父進程發送處理消息read()將接收到的緩沖區打成請求頭結構radrecv()根據不同請求包類型，調用用戶自定義回調函數響應模塊如認證處理rad_authenticate()等處理完

29、畢，返回繼續等待下一個請求圖4-6 子進程處理請求包流程從圖中可以看出，協議棧的用戶只需要編寫用戶處理請求包的回調函數，對于其它過程則可以不用關心。測試環境和方法一個可擴展的AAA 協議棧13本協議棧的測試環境可以象開發環境一樣，有多種組合。下面選取其中一種，以協議棧為基礎的RADIUS 系統，如圖4-7 所示。本地RADIUS服務員ORACLE數據庫遠端RADIUS服務員RADIUS客戶端測試程序圖4-7 協議棧測試環境其中本地 RADIUS 服務員接收發自RADIUS 客戶端的請求，ORACLE 數據庫作為存儲用戶數據和配置信息的服務器。遠程RADIUS 服務員接收漫游用戶的認證請求。測試

30、程序負責產生測試呼叫。測試分為兩個部分：功能測試和性能測試。功能測試包括對RADIUS 服務員中是否滿足RFC2138 和RFC2139 中規定功能的測試；性能測試包括在大并發用戶量下系統的響應時間和正確率。需要編寫一個能完成測試要求的測試程序。此測試程序運行于RADIUS 客戶端，通過進程間通信模仿調用方程序。測試前還要編寫一個模擬數據生成程序，它負責從數據庫中抽取數據，模仿呼叫數據。接口回調函數開發者通過回調函數來使用本協議棧，在請求包處理回調函數中，開發者可以使用協議棧提供的各種實用函數，包括屬性提取函數、加密解密函數、包發送接收函數、打包函數和訪問數據庫函數。一個典型的回調函數例子的流

31、程圖如下。一個可擴展的AAA 協議棧14判斷用戶名長度是否合法判斷是否有屬性getattribute()抽取SESSION_INDEX屬性放入響應鏈表中抽取相應請求屬性getattribute()應用客戶端口令解密請求口令decrypt_password()調TUXEDO訪問數據庫取口令get_password()判斷為正確，并發送響應send_accept()判斷為錯誤，并發送響應send_reject()圖4-8 典型回調函數流程圖第五章協議棧功能特點協議實現全、互通性較高：本協議棧基本全部實現了IETF 中關于RADIUS 的相關協議。由于本協議棧完全遵守IEFT 的關于RADIUS 的

32、各個協議，所以在以本協議棧為基礎開發的RADIUS 系統可以完全實現互通，在和其它標準RADIUS 系統也可以實現較大程度上的互通。多種驗證類型：在驗證過程中，RAS 和RADIUS 服務員傳送口令信息，這個口令信息通過RAS 和RADIUS 服務員之間的共享密鑰加密?？诹钚畔⒃从谟脩糨斎?，根據用戶選擇可以有以下三種：1、PAP（Password Authentication Protocol 口令驗證協議）非常簡單，用戶發送口令給RADIUS 服務員，RADIUS 服務員通過數據庫或操作系統來驗證。用戶發送口令給RAS 的過程中，口令以明文方式傳送。RAS 傳送口令給RADIUS 的過程中，

33、使用共享密鑰加密。最后RADIUS 服務員以口令明文的方式進行驗證。2、CHAP（Challenge Handshake Authentication Protocol 挑戰握手驗證協議）避免在任何通信連接中使用口令明文。在CHAP 中，RAS 首先生成一個隨機數（稱為挑戰）并發送給用戶，用戶的PPP 端生成一個由口令和挑戰組成的單向摘要并發送給RAS，由于摘要是單向加密，RADIUS 服務員不能從摘要中恢復口令，所以它使用本地數據庫中存儲的用戶口令用同樣方法計算出摘要和接收的摘要比較，如果一樣則驗證通過。3、MS-CHAP (Microsoft Challenge Handshake一個可擴

34、展的AAA 協議棧15Authentication Protocol 微軟挑戰握手驗證協議)是微軟提出的類似于CHAP 而整合入微軟操作系統中的驗證方法，它可以在操作系統之上采用不同級別：本地用戶、域用戶、域組、主機用戶、主機組合外部數據庫等來驗證用戶。二次開發工作量少，容易擴充：由于協議棧已經完成了開發RADIUS 系統所需的大部分工作，用戶只需要開發少量的回調函數，完成自己的特定需要，所以可以快速開發。由于協議棧的實現是基于協議的包處理過程，所以用戶可以根據協議的變化和需求的變更，不斷改進實現，而不需要太多工作量。運行穩定：由于協議棧采用進程池的方式實現，所占用的存一定，系統開銷最小。所以

35、不會大量占用系統資源（CPU 處理時間和存），不會出現因請求數量變化而使系統資源的占用發生顛簸。更不會出現存泄漏等錯誤。性能：由于我們對協議棧的實現做到精益求精，采用高效的實現方法，優化代碼的設計，所以使用本協議棧開發的RADIUS 系統在同檔次的服務器上運行效率比其它系統要高。一般來說，在主頻為300MHz 的主機上，其它系統可以實現500 個/秒的認證速度，而使用本協議棧開發的RADIUS 系統可以實現1000 個每秒。多種用戶驗證手段：本協議棧有多個模塊支持多種數據庫訪問方式，用戶數據可以存放在以下幾個形式中，文本文件、UNIX DBM、MYSQL、ORACLE、MS-SQL 等。多種日

36、志方法：詳細錯誤信息輸出到本地日志、系統日志、數據庫中?？梢詭椭芾韱T和開發人員迅速找到錯誤原因，實時掌握系統狀態?？缙脚_運行：本協議棧可以運行在多個平臺之上。由于是基于進程實現，所以不會因為各個操作系統對線程實現不同而引發差異。本協議棧在 HP-UX 1 1.00、IBMRS6000 AIX 4.2、Redhat Linux 5.2、Slackware Linux 2.0.30、Solaris 2.7.1、Solaris x86 2.7.1、SunOS 4.1.3、WindowsNT/2000 上測試成功。第六章協議棧應用方法本協議棧的應用可以分為以下幾個步驟：1、了解RADIUS 協議概況

37、：開發者必須對RFC2138、RFC2139 有所了解，雖然不用了解包的發送和接收、加密解密細節，但對協議的使用步驟和包的格式定義必須了解。2、了解協議棧和實用函數：開發者必須掌握本協議棧的邏輯流程，了解函數的定義和調用的順序。3、編寫用戶回調接口函數：根據自定義的不同需要，對每個類型的請求進行處理。4、連接編譯整個協議棧：選擇不同運行模塊，包括不同的驗證方式、訪問數據庫的類型等，在操作系統上運行編譯器。一個可擴展的AAA 協議棧165、配置RADIUS 系統：在系統運行之前，需要根據不同的系統組成部分，選擇適當方式來配置系統，例如：主機地址、端口、代理員的列表、客戶端的列表等。在使用本協議棧

38、時應注意以下幾個問題：1、字典文件和屬性的定義：由于不同廠商對屬性和屬性值的定義值不同，所以應注意區別，防止屬性數據類型不匹配。2、確定操作系統參數如最大打開文件數、信號燈數等符合需要。3、盡量在用戶回調函數中使用靜態存，防止動態存使用不慎而引起的存泄漏和系統崩潰。4、根據不同需要，連接不同模塊，防止占用系統過多。5、減少用戶處理執行時間，以利于系統整體的運行性能。第七章結論協議棧實現系統與相關系統比較采用本協議棧編寫的AAA 系統與其它典型RADIUS 實現系統比較如下表：系統本實現 Livingston1 Merit10 Ascend11 Freeradius12協議實現全部全部全部全部全

39、部認證方式一般一般一般一般多功能多一般一般一般多兼容性一般好一般一般一般性能好一般一般一般好擴展性好一般一般一般好測試工具全面簡單簡單簡單簡單結論由于Internet 不斷發展，用戶的接入越來越為人們關注。而防火墻和VPN 中的不斷使用，使RADIUS 協議也日益成為工業事實標準。隨著網絡協議不斷增多，使用協議棧來開發網絡通信程序是近年來流行的趨勢。開發一個可供快速組建RADIUS 系統的協議棧是一個必不可少的基礎工具。一個可擴展的AAA 協議棧17本文通過集成關于 RADIUS 的若干協議，實現一個AAA 協議棧，使得開發基于RADIUS 協議的安全認證系統變得更加容易。通過測試，本協議棧在

40、同等環境條件下，系統的功能和性能達到相近系統的前列。不足之處和進一步的工作雖然我們做了大量工作，但在以下幾個方面還存在著不足：1、對不同系統的各種屬性的處理還不夠全面。2、認證中的驗證類型還需擴充。3、與其它安全認證系統的互通性有待提高。今后進一步的工作是：1、實現最新的RADIUS 協議RFC286513、RFC286614。2、改進協議棧，使之能運行于集群之上，提高系統性能。3、對數據庫的訪問中增加LDAP（輕型目錄訪問協議）的支持。4、加入負載平衡算法，使系統不同進程能發揮更大效率。5、增強與其它RADIUS 系統的互通性。6、支持TACACS+協議15，TACACS 終端訪問控制器接入

41、控制系統協議。定義于RFC1492 中。TACACS+增強型。類似于RADIUS 的AAA 協議，與RADIUS 不同之處在于：傳輸協議使用TCP 而不是UDP。RADIUS 只加密口令字段，而TACACS+加密整個包凈荷。TACACS+允許驗證和授權分離，而RADIUS 中驗證和授權是集成的。7、支持Diameter 協議16。IETF 著眼的下一代AAA 協議。一個全新輕量級的，基于端點的。提供可擴展的基礎來引進新策略和AAA 服務。繼承RADIUS 的機能。突破RADIUS 協議限制，允許服務員向客戶端發送統一消息。使用重傳和失敗恢復算法。提供端到端的安全機制。支持漫游和移動IP 網絡。

42、參考文獻1.Lucent, “Remote Authentication Dial-In User Service”,.livingston./marketing/whitepapers/radius_paper.html,一個可擴展的AAA 協議棧1819922.Internet Engineering Task Force (IETF) Authentication, Authorization,and Accounting (AAA) Working Group Charter; available at./html.charters/aaa-charter.html.3.“Stacks

43、 of Internet Telephony”, ., 20004.C. Rigney, A. Rubens, W. Simpson, and S. Willens, “Remote AuthenticationDial In User Service”, IETF Network Working Group, April 1997.RFC2138.5.C. Rigney, “RADIUS Accounting”, IETF Network Working Group, April 1997.RFC2139.6.B. Aboba, G. Zorn “RADIUS Authentication

44、Client MIB”, IETF NetworkWorking Group, June 1999. RFC2618.7.B. Aboba, G. Zorn “RADIUS Authentication Server MIB”, IETF NetworkWorking Group, June 1999. RFC2619.8.B. Aboba, G. Zorn “RADIUS Accounting Client MIB”, IETF Network WorkingGroup, June 1999. RFC2620.9.B. Aboba, G. Zorn “RADIUS Accounting Se

45、rver MIB”, IETF Network WorkingGroup, June 1999. RFC2621.10. University of Michigan and Merit Network, Inc. “Merit AAA Server”,199211. Ascend Communications, Inc. “Ascend RADIUS”, 199612. “Free RADIUS Project”, ., 200013. C. Rigney, A. Rubens, W. Simpson, and S. Willens, “RemoteAuthentication Dial I

46、n User Service”, IETF Network Working Group, June2000. RFC2865.14. C. Rigney, “RADIUS Accounting”, IETF Network Working Group, June2000. RFC2866.15. C. Finseth, An Access Control Protocol, Sometimes Called TACACS,IETF RFC 1492, July 1993; available at/in-notes/rfc1492.txt.16. P.R. Calhoun, A.C. Rube

47、ns, and H. Akhtar, Diameter Base Protocol,IETF AAA Working Group, Internet draft, Oct. 1999, work in progress.一個可擴展的AAA 協議棧19致在此，首先向我的導師鞠九濱教授表示深深的意！從本科論文開始，鞠九濱教授以他嚴謹的治學態度、淵博的學識、敏銳的思維和孜孜不倦的工作作風對我進行了悉心的教誨，使我受益終生。同時還要向春陽高級工程師表示感，老師一絲不茍的工作作風非常值得我的學習。向師兄鈳、猛表示衷心的感。他們在科研上幫我攻克難關，給了我許多無私的關心和幫助。感研究小組成員靜、廣艷、于海

48、超，是他們使我在團結協作中不斷成長。特別感于秀峰老師、胡成全老師、胡亮老師和房至一老師對我的幫助。一個可擴展的AAA 協議棧20論文摘要認證（Authentication）、授權（Authorization）、記賬（Accounting）是網絡接入的三個重要需求。滿足這些要求的RADIUS（Remote Authentication Dial-In UserService 用戶遠程撥號驗證服務）協議作為IETF（Internet Engine Tasks Force互聯網工程任務組）定義的標準協議已經越來越被大多數ISP、ITSP 和安全系統所認可。這樣，開發符合RADIUS 協議的用戶接入認

49、證、授權和記賬的軟件成為構筑ISP、電信運營商、安全網絡系統中的必要部分。現行的RADIUS 開發雖然部分滿足了用戶的需求，但存在幾個關鍵問題，如開發者不能利用已有存在的系統，重復勞動，開發周期長；各種系統實現方式差異很大，不利于維護擴充；軟件特定平臺，不能跨越平臺使用；對協議包理解方式不同，不能互通漫游。作為一個可擴充的AAA 協議棧軟件包，用戶可以在AAA 協議棧的基礎之上，選擇自己所需要的運行模塊和連接方式，編寫符合自己需要的用戶回調函數和全局設置接口，就可以完成一個標準的RADIUS 系統。用戶使用本協議棧開發AAA 系統時，可以脫離編寫協議時的各種繁瑣過程，無需考慮協議的語法和數據包的結構，并且使系統所覆蓋的協議最多。采用這種方法開發的RADIUS 系統具有符合國際標準協議、使用簡便、開發周期短、系統靈活性高、易于擴充和與系統間可互通漫游的特點。一個可擴展的AAA 協議棧21AbstractAuthentication, Authorization and Accounting are three crucial requirementsfor network access. To