遠端用戶撥入驗證服務

遠端用戶撥入驗證服務（RADIUS, Remote Authentication Dial In User Service）是一個AAA（英語：AAA_protocol）協議^{[註 1]}，通常用於網絡存取、或流動IP服務，適用於局域網及漫遊服務。

RADIUS協議包括RADIUS驗證協議（對應AAA的驗證和授權）和RADIUS記賬協議，分別定義於IETF RFC 2865和RFC 2866。

協議

客戶端-服務器結構

RADIUS協議是一種基於主從式架構的協議。RADIUS協議中的客戶端是對用戶（人或者計算機）提供網絡連接服務的器材，對服務器提出驗證和計費要求。服務器針對客戶端的通過進行驗證和計費給予應答。服務器只有針對客戶端的請求進行應答，而無法反方向地對用戶進行服務停止等的請求。

RADIUS客戶端的實例

因特網連接服務中，撥號呼叫裝置和寬帶接入服務器（BAS、Broadband Access Server）等網絡接入服務器（NAS、Network Access Server）即為RADIUS客戶端^[1]。（雖然名字含有「服務器」，但從RADIUS協議的角度來看是客戶端。）

無線LAN環境中的無線接取器和VLAN中的交換機等都是。

在內容提供的服務中，Web 服務器起到RADIUS客戶端的作用。

在移動電話網絡（例如LTE等）網絡中，核心網節點作為RADIUS客戶端，使用RADIUS的認證和記賬功能。^[2]

協議的概要

RADIUS協議使用UDP協議承載。RADIUS協議自身不具備會話管理機制，UDP也缺乏相應機制，因此RADIUS的路徑管理和傳輸可靠性需要由使用RADIUS協議的應用程序來實現。^[1]

客戶端對服務器提出「RADIUS請求包」，服務器對客戶端發送「RADIUS應答包」。

雙方的數據包，頭部分由20個 8位元和「屬性」組成。頭部分包括類別碼（Code）1個8位元、識別碼（Identifier）1個8位元、數據包整體長度2個8位元、驗證碼（Authenticator）16個8位元。識別碼根據客戶端決定的需求而設定，服務器根據根據請求包的驗證碼生成應答包的驗證碼里，因為客戶端需要在收到的應答包與之前發出的請求包匹配。客戶端可以僅用累計數值編號來設置驗證碼，但驗證碼並不必然是序列號。驗證碼是為了證明無發送者偽裝和篡改。屬性部分包含任意個屬性（AVP，Attribute Value Pair，字面上為屬性值對）。屬性採用TLV格式，即「類型-長度-值（英語：type-length-value）」格式^[3]。屬性値對由1個8位元的屬性編號、1個8位元的長度，以及屬性的値組成。値的類型可以是4個8位元的整數値、4個8位元的IP地址、1 - 253個8位元的文字串等。

對於每個屬性編號，每個屬性値對里值的含義在RFC文件里均有規定，還可以通過給屬性編號賦予新的定義來增加使用目的，RADIUS協議的靈活性所在也是其最大的特徵。但是一般不推薦各個機器產商為各自目的獨自給屬性標號賦值。產商特有功能應做為屬性編號26號(Vendor Specific)的值與產商編號一起加到數據里。屬性編號 26 號的屬性値對一般稱為 VSA (Vendor Specific Attribute) 。廠家編號由IANA進行管理和賦予。

協議為了實現驗證和計費，規定了各種相應的屬性。為實現驗證，用戶名和密碼各有屬性編號。撥號上網使用PPP時針對PPP用的驗證協議PAP、CHAP、EAP均備有各自的屬性編號。為實現計費，有使用秒數、收發數據量等的屬性編號。

RADIUS分組的最大長度，在RADIUS驗證協議中是4096個8位元、RADIUS計費協議中是4095個8位元，這個差異據說並沒有特殊含義，而是 RFC 當初的錯字將錯就錯地沿用下來的緣故。

協議流程

一個常見的RADIUS認證、計費協議的流程如下。

+------+                         +--------------+     +------------------+     +------------------+
| 用戶 |                         | RADIUS客戶端 |     | RADIUS認證服務端 |     | RADIUS計費服務端 |
+--+---+                         +------+-------+     +--------+---------+     +---------+--------+
   | 用戶發起連接請求並提供用戶名、密碼 |                      |                         |
   |----------------------------------->| 認證請求消息         |                         |
   |                                    |--------------------->|                         |
   |                                    | 認證接受/拒絕消息    |                         |
   | 通知用戶認證結果                   |<---------------------|                         |
   |<-----------------------------------|                                                |
   |                                    |（若認證已被接受）                              |
   |                                    |  計費請求（開始）消息                           |
   |                                    |----------------------------------------------->|
   |                                    | 計費響應消息                                   |
   |                                    |<-----------------------------------------------|
   |                                    |                                                |
   |                            ................                                         |
   |                            . 用戶使用服務 .                                         |
   |                            ................                                         |
   |                                    | （可選）                                       |
   |                                    | 計費請求（中間）消息                           |
   |                                    |----------------------------------------------->|
   |                                    | 計費響應消息                                   |            |
   |                                    |<-----------------------------------------------|
   | 用戶請求斷開連接                   |                                                |
   |----------------------------------->| 計費請求（結束）消息                           |
   |                                    |----------------------------------------------->|
   |                                    | 計費響應消息                                   |
   | 通知用戶連接斷開                   |<-----------------------------------------------|
   |<-----------------------------------|                                                |
   |                                    |                                                |

共享密碼

UDP與TCP不同，無法識別偽裝送信者和數據篡改。因此僅靠通信對方的IP地址是不足以信任通信內容的。為了防止偽裝和篡改，RADIUS客戶端和服務器之間共享一個叫「共享密碼」的密鑰字符串，將數據包的內容和共享密碼得到的摘要信息配給驗證符號和屬性值。應該為每對 RADIUS客戶端和服務器準備一個共享密碼。針對一個RADIUS服務器只用一個密碼而與所有RADIUS客戶端都共用會造成安全上的重大隱患。另外，從安全的角度來說，共享密碼的內容若被第三方泄露也是一大問題^[4]。

代理

自身作為RADIUS服務器，而把實際的驗證和計費處理委託其他RADIUS服務器的情況即為「RADIUS代理服務器」。也就是說本身既是RADIUS服務器也是RADIUS客戶端，將需求「轉送」。

可以通過判斷用戶名的字符串改變轉送地址。比如用戶名做成含有電子郵件地址「@」符號和域名的字符串，根據不同的域名部分字符串轉送到其他RADIUS服務器上。這種技術廣泛被利用於 ISP（互聯網服務提供商）之間的漫遊服務等。上述例子中用於判斷轉送目的類似域名的部分通常被稱為 Realm。

AAA

RADIUS協議是一種AAA（英語：AAA_protocol）協議，但由於RADIUS協議本身創建於AAA模式之前，因此，RADIUS協議中並沒有區分「驗證」和「授權」，而是合為「驗證」處理，因此RADIUS客戶端在實際操作中無法知道被拒絕的原因是由於密碼錯誤還是因為沒有權限。

IEEE 802.1X

IEEE 802.1X是以太網中一個控制可否使用局域網的一個協議。通過使用IEEE 802.1X和RADIUS協議，可以對僅通過RADIUS服務器驗證的用戶允許局域網服務。當然，為此需要配備IEEE 802.1X以及RADIUS協議雙方能使用的無線接入點或VLAN開關。另外「802.1x」中的 X 一般為大寫，這是因為小寫x易被人誤解其像數學中 $x$ 一樣可代表任意參數。

IEEE802.1X和RADIUS協議均沒有規定實際的驗證步驟。實際的驗證中通常使用 EAP-TLS、PEAP、EAP-TTLS 等 EAP上的驗證步驟進行。為實現 EAP 驗證的數據交換，用戶終端和接入點或開關之間的以太網使用 IEEE 802.1X，接入點或開關與RADIUS服務器之間使用RADIUS協議進行中継。

EAP-TLS 對於基於TLS數字證書進行相互驗證（為防止偽裝服務提供者）這一點雖然很重要，但數字證書的管理和運用對於一般機構是一個很大的負擔。PEAP 和 EAP-TTLS 的驗證步驟是在創建以 TLS 加密的通訊線路後再進行密碼信息的交換。EAP-TLS 與 PEAP・EAP-TTLS 的對比可以參照比較是通過網頁瀏覽器的TLS中利用數字證書進行相互驗證還是 SSL 上的密碼驗證。

應用實例

ISP（互聯網服務提供商）
移動電話的網絡連接服務
無線 LAN、VLAN
Web 上提供收費內容的服務

定義

通過下述 RFC 文件定義：

RFC 2865 - RADIUS驗證協議
RFC 2866 - RADIUS計費協議
RFC 2867 - 為通道協議的RADIUS計費拓展
RFC 2868 - 通道協議中使用的RADIUS屬性
RFC 2869 - RADIUS協議拓展
RFC 3162 - IPv6網絡中RADIUS協議的使用
RFC 3579 - RADIUS協議中EAP(RFC 2284)的使用
RFC 3580 - IEEE 802.1X中RADIUS協議的使用指南

注釋

^ AAA協議是同時兼顧驗證（authentication）、授權（authorization）及計帳（accounting）三種服務的協議

參考資料

^ ^1.0 ^1.1 How Does RADIUS Work?. Cisco. 2006-01-19 [2019-08-29]. （原始內容存檔於2021-05-04）（英語）.
^ Ayman ElNashar; Mohamed A. El-saidny; Mahmoud Sherif. Design, Deployment and Performance of 4G-LTE Networks: A Practical Approach. John Wiley & Sons. 2014-05-13: 608. ISBN 9781118703441.
^ RADIUS认证、授权和计费. 華為. 2018-09-04 [2019-08-29].
^ Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger. MD5 considered harmful today - Creating a rogue CA certificate. Technische Universiteit Eindhoven. 2008-12-08 [2009-04-19]. （原始內容存檔於2017-09-20）.

外部連結

IEEE 802.1X （頁面存檔備份，存於網際網路檔案館）

Copyright (c) 2004 by Accense Technology, Inc.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License Version 1.1 published by the Free Software Foundation.
本文檔允許在基於 GNU Free Documentation License Version 1.1 規定的條件下複製、發布和變更。

[1] AAA協議是同時兼顧驗證（authentication）、授權（authorization）及計帳（accounting）三種服務的協議

[Cisco-2] 1.0 ^1.1 How Does RADIUS Work?. Cisco. 2006-01-19 [2019-08-29]. （原始內容存檔於2021-05-04）（英語）.

[ElNashar-3] Ayman ElNashar; Mohamed A. El-saidny; Mahmoud Sherif. Design, Deployment and Performance of 4G-LTE Networks: A Practical Approach. John Wiley & Sons. 2014-05-13: 608. ISBN 9781118703441.

[华为-4] RADIUS认证、授权和计费. 華為. 2018-09-04 [2019-08-29].

[5] Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger. MD5 considered harmful today - Creating a rogue CA certificate. Technische Universiteit Eindhoven. 2008-12-08 [2009-04-19]. （原始內容存檔於2017-09-20）.

[註 1]

[1]

[2]

[3]

[4]