Radius 認證協議介紹-兼rfc導讀

老規矩, 先看維基: 遠端用戶撥入驗證服務（RADIUS, Remote Authentication Dial In User Service）是一個AAA協議，意思就是同時兼顧驗證（authentication）、受權（authorization）及計費（accounting）三種服務的一種網絡傳輸協議（protocol），一般用於網絡存取、或流動IP服務，適用於局域網及漫遊服務。
https://zh.wikipedia.org/wiki/RADIUS

上面的介紹來自維基百科. 說的權威,可是不太好懂. 咱們這裏再詳細介紹如下幾個問題, 但願能給初次接觸radius的小夥伴有所幫助:

1) Radius 究竟是什麼.
2) Radius 應用和工做方式.
3) Radius 的協議細節.

一. Radius 究竟是什麼.

上面維基百科 說的很具體了, Radius 遠程撥入服務, 它集成了 認證, 受權 和計費功能. 怎麼理解這個問題呢. 舉個不是十分貼切的栗子, 寬帶 ADSL 撥號上網的後臺認證和計費系統就能夠用radius, 或者 V-P-N 系統的後臺驗證計費系統就是radius 的使用場景.

固然, 並不能把 radius 的概念限制在 「撥號」, 實際上, 不光是這種 「撥號」 服務, 其餘幾乎任何服務, 均可以使用 radius 來進行認證,受權和計費服務.

二. Radius 的工做方式.

咱們以搭建 V-P-N 爲例, 介紹radius的工做方式.

圖中有三個角色, v-p-n(下面簡稱XXX服務器)服務器, 客戶端 和radius 服務器.

Radius 主要工做在 xxx 服務器和 Radius 服務器之間, 客戶幾乎直接接觸不到.

對於radius 協議來講, xxx 服務器其實是 一個client, 而 radius 服務器是真正提供服務的server.
(若是看英文文檔的話, rfc有專門解釋 client 和server 的章節.)

這樣看起來, radius 更像是 C/S 模式的協議.

因此後面的討論主要集中在 xxx 服務器和 radius 服務器之間, 請自行腦補.

三. Radius 的協議細節.
這裏仍是介紹一下大致的細節, 重點介紹如何閱讀rfc. 有了方向,再讀rfc就容易多了. 不會詳細介紹每一個字節如何生成, 這是rfc的責任.

做爲參考, 這是 radius 的rfc : https://tools.ietf.org/html/rfc2865

1) 首先, radius 是基於udp的協議, 全部數據包都是封裝在udp協議中.
至於爲何是udp,而不是tcp, 請參看 rfc 的解釋: Why udp?

2) radius 協議包的格式.
基本上, radius 協議有四種包:

Access-Request
Access-Accept
Access-Reject
Access-Challenge

這四種包都有統一的格式: https://tools.ietf.org/html/rfc2865#page-13

這四種包在 xxx服務器和radius 服務器之間通訊,來完成整個過程.

上圖中, 前面三個交互是必須的, 後面兩個綠色的帶星號的交互不是必須的.

首先, xxx 服務器向radius發送 Access-Request 數據包, 包含用戶信息和密碼哈希等等信息用於認證.
此時服務器有四個選擇:
第一, 若是認證經過,就返回一個 「Access-Accept」 數據包, 認證完成.
第二, 若是認證不經過,則返回 「Access-Reject」,認證失敗.
第三, 若是服務器認爲必要, 能夠返回一個」Access-Challenge」 數據包, 讓用戶提供更多的附加信息以完成認證. 而xxx服務器在收到 「Access-Challenge」 消息以後, 須要向用戶索要必須的附加信息,而後組成一個新的 」 Access-Request」 數據包發給radius服務器來繼續認證. 此時服務器能夠重複第一,或第二.
第四, 若是 「Access-Request」 數據包有問題, 服務器還能夠採起 「靜默丟棄」(silently discard) 的方式, 不作任何反應.

這就是主要的通訊流程了.

通常來說, 做爲 radius 的客戶端, 「Access-Request」 數據包的格式比較重要. 他負責將認證信息加密傳輸給radius 服務器.
咱們再介紹一下 「Access-Request」 數據包的格式:
https://tools.ietf.org/html/rfc2865#page-17

0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Request Authenticator                     |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

咱們如今介紹後面的 「Attributes」 數據區. 這裏包含了用戶的密碼信息.
radius 協議將用戶名,密碼等等身份信息 都封裝成一個一個的 attribute.
舉個栗子, 可能最少須要兩個 attribute, 一個是用戶名, 另外一個是password hash. 這是最簡單的方式了.

https://tools.ietf.org/html/rfc2865#page-22

目前, radius 的密碼封裝方式有兩種,
一種是: User-Password, https://tools.ietf.org/html/rfc2865#page-27
另外一種是: CHAP-Password, https://tools.ietf.org/html/rfc2865#page-28

兩種方式只是密碼的hash計算方法不同而已. 具體生成方法比較明確. rfc 寫的很明顯,就很少說了.

到這裏, radius 認證協議的客戶端過程基本完成了. 至於服務端, 通常不用本身來寫. 可使用開源的現成服務端.

歡迎訪問個人我的獨立博客: https://blog.byNeil.com