歷史 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組網示意如圖所示,其中RADIUS套用在AAA伺服器上對用戶進行認證、授權和計費服務。
AAA組網 圖中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);
RADIUS協定結構 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)
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)。