遠端用戶撥入驗證服務

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