遠端使用者撥入驗證服務

遠端使用者撥入驗證服務（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]