曆史
RADIUS協議最初是由Livingston公司提出的,原先的目的是為撥号用戶進行認證和計費。後來經過多次改進,形成了一項通用的認證計費協議。
創立于1966年的Merit Network, Inc.是密歇根大學的一家非營利公司,其業務是運行維護該校的網絡互聯MichNet。1987年,Merit在美國NSF(國家科學基金會)的招标中勝出,赢得了NSFnet(即Internet前身)的運營合同。因為NSFnet是基于IP的網絡,而MichNet卻基于專有網絡協議,Merit面對着如何将MichNet的專有網絡協議演變為IP協議,同時也要把MichNet上的大量撥号業務以及其相關專有協議移植到IP網絡上來。
1991年,Merit決定招标撥号服務器供應商,幾個月後,一家叫Livingston的公司提出了建議,冠名為RADIUS,并為此獲得了合同。
1992年秋天,IETF的NASREQ工作組成立,随之提交了RADIUS作為草案。很快,RADIUS成為事實上的網絡接入标準,幾乎所有的網絡接入服務器廠商均實現了該協議。
1997年,RADIUS RFC2058發表,随後是RFC2138,最新的RADIUS RFC2865發表于2000年6月。
功能描述
組網應用
常見的AAA組網示意如圖1所示,其中RADIUS應用在AAA服務器上對用戶進行認證、授權和計費服務。
圖1中NAS(網絡接入服務器)作為RADIUS客戶端,向遠程接入用戶提供接入及與RADIUS服務器交互的服務。RADIUS服務器上則存儲用戶的身份信息、授權信息以及訪問記錄,對用戶進行認證、授權和計費服務。
工作原理
用戶接入NAS,NAS使用Access-Require數據包向RADIUS服務器提交用戶信息,包括用戶名、密碼等相關信息,其中用戶密碼是經過MD5加密的,雙方使用共享密鑰,這個密鑰不經過網絡傳播;RADIUS服務器對用戶名和密碼的合法性進行檢驗,必要時可以提出一個Challenge,要求進一步對用戶認證,也可以對NAS進行類似的認證;如果合法,給NAS返回Access-Accept數據包,允許用戶進行下一步工作,否則返回Access-Reject數據包,拒絕用戶訪問;如果允許訪問,NAS向RADIUS服務器提出計費請求Account- Require,RADIUS服務器響應Account-Accept,對用戶的計費開始,同時用戶可以進行自己的相關操作。
RADIUS還支持代理和漫遊功能。簡單地說,代理就是一台服務器,可以作為其他RADIUS服務器的代理,負責轉發RADIUS認證和計費數據包。所謂漫遊功能,就是代理的一個具體實現,這樣可以讓用戶通過本來和其無關的RADIUS服務器進行認證,用戶到非歸屬運營商所在地也可以得到服務,也可以實現虛拟運營。
RADIUS服務器和NAS服務器通過UDP協議進行通信,RADIUS服務器的1812端口負責認證,1813端口負責計費工作。采用UDP的基本考慮是因為NAS和RADIUS服務器大多在同一個局域網中,使用UDP更加快捷方便,而且UDP是無連接的,會減輕RADIUS的壓力,也更安全。
RADIUS協議還規定了重傳機制。如果NAS向某個RADIUS服務器提交請求沒有收到返回信息,那麼可以要求備份RADIUS服務器重傳。由于有多個備份RADIUS服務器,因此NAS進行重傳的時候,可以采用輪詢的方法。如果備份RADIUS服務器的密鑰和以前RADIUS服務器的密鑰不同,則需要重新進行認證。
優勢特點
RADIUS協議承載于UDP之上,官方指定端口号為認證授權端口1812、計費端口1813。RADIUS協議簡單明确、擴展性好,因此得到了廣泛應用,具有以下特點:
采用通用的客戶端/服務器結構組網
NAS作為RADIUS的客戶端負責将用戶信息傳遞給指定的RADIUS服務器,然後處理RADIUS服務器的返回結果。RADIUS服務器負責接收用戶的連接請求,對用戶進行認證,給客戶端返回用戶配置信息。
采用共享密鑰保證網絡傳輸安全性
客戶端與RADIUS服務器之間的交互是通過共享密鑰來進行相互認證的,以減少在不安全的網絡中用戶密碼被偵聽到的可能性。
具有良好的可擴展性
RADIUS是一種可擴展的協議,所有的交互報文由多個不同長度的ALV(Attribute-Length-Value)三元組組成,新增加屬性和屬性值不會破壞到協議的原有實現。因此RADIUS協議也支持設備廠商擴充廠家專有屬性。
協議認證機制靈活
RADIUS協議認證機制靈活,支持多種認證用戶的方式。如果用戶提供了用戶名和用戶密碼的明文,RADIUS協議能夠支持PAP、CHAP、UNIX login等多種認證方式。
RADIUS協議簡單明确、擴展性強,因此得到了廣泛應用。在普通電話撥号上網、ADSL撥号上網、社區寬帶上網、VPDN業務、移動電話預付費等業務中都能見到RADIUS的身影。
協議結構
Code域長度為1個字節,用于标明RADIUS報文的類型,如果Code域中的内容是無效值,報文将被丢棄,有效值如下:
1、請求訪問(Access-Request);
2、接收訪問(Access-Accept);
3、拒絕訪問(Access-Reject);
4、計費請求(Accounting-Request);
5、計費響應(Accounting-Response);
11、挑戰訪問(Access-Challenge);
12、服務器狀況(Status-Server — Experimental);
13、客戶機狀況(Status-Client — Experimental);
255、預留(Reserved)
Identifier― 匹配請求和響應的标識符。
Length― 信息大小,包括頭部。
Authenticator域占用16個字節,用于Radius Client 和Server之間消息認證的有效性,和密碼隐藏算法。訪問請求Access-Request報文中的認證字的值是16字節随機數,認證字的值要不能被預測并且在一個共享密鑰的生命期内唯一。
1.訪問請求認證字
在Access-Request包中認證字的值是16字節随機數,認證字的值要不能被預測,并且在一個共享密鑰的生命期内唯一;
2.訪問回應認證字
Access-Accept Access-Reject 和Access-Challenge包中的認證字稱為訪問回應認證字,訪問回應認證字的值定義為MD5(Code+ID+Length+RequestAuth+Attributes+Secret);
3.計費請求認證字
在計費請求包中的認證字域稱為計費請求認證字,它是一個16字節的MD5校驗和,計費請求認證字的值定義為MD5(Code + Identifier + Length + 16 zero octets + request attributes +shared secret);
4.計費回應認證字
在計費回應報文中的認證字域稱為計費回應認證字,它的值定義為MD5(Accounting-Response Code + Identifier + Length + the RequestAuthenticator field from the Accounting-Request packet being replied to +the response attributes + shared secret);
消息交互
radius服務器對用戶的認證過程通常需要利用nas等設備的代理認證功能,radius客戶端和radius 服務器之間通過共享密鑰認證相互間交互的消息,用戶密碼采用密文方式在網絡上傳輸,增強了安全性。radius 協議合并了認證和授權過程,即響應報文中攜帶了授權信息。
基本交互步驟如下:
(1) 用戶輸入用戶名和口令;
(2) radius客戶端根據獲取的用戶名和口令,向radius服務器發送認證請求包(access-request)。
(3) radius服務器将該用戶信息與users 數據庫信息進行對比分析,如果認證成功,則将用戶的權限信息以認證響應包(access-accept)發送給radius客戶端;如果認證失敗,則返回access-reject 響應包。
(4) radius客戶端根據接收到的認證結果接入/拒絕用戶。如果可以接入用戶,則radius客戶端向radius服務器發送計費開始請求包(accounting-request),status-type 取值為start;
(5) radius服務器返回計費開始響應包(accounting-response);
(6) radius客戶端向radius服務器發送計費停止請求包(accounting-request),status-type 取值為stop;
(7) radius服務器返回計費結束響應包(accounting-response)。



















