遠程撥入使用者認證服務(RADIUS)

遠程撥入使用者認證服務(RADIUS)

http://91mail.51.net提供翻譯，僅供學習交流

不得作其他用途，否則後果自負

摘要：本文檔描述了一種在希望對它的串連進行認證的網路接入伺服器與共用證明伺服器之間傳送認證、授權和配置資訊的一種協議。

應用提示：篇備忘錄說明的是RADIUS協議。早期的RADIUS配置是使用UDP連接埠，連接埠號碼是1645，它是與資料量度（datametrics）服務衝突。RADIUS正式分配的連接埠號碼是1812

1. 介紹

??? 這篇文檔廢除了RFC2138[1]。這篇文檔對RFC2138的修改可以在“更改記錄（Chang Log）”附錄中找到。

??? 系統管理使用者大量分散的串列線（serial line）或調製池（modem pools）使用者會產生一種明顯的管理支援需求。既然調製池（modem pools）已被解釋為一種到達外部世界的串連，則他們需要在安全、授權和計費方面給予認真的關注，通過管理一個使用者資料庫，可以把這種關注良好的體現出來，此資料庫兼顧了認證（驗證使用者名稱和密碼）和配置資訊細節——交付給使用者的服務類型(如：串列線路介面協議（SLIP），端對端協議（PPP），遠端連線的標準協議（Telnet），遠程登入（rLogin）)。

客戶/服務模式(Client/Server)

??? 網路接入伺服器（Network Access Server）是作為RADIUS的用戶端運作的。這個用戶端負責將使用者資訊傳遞給指定的RADIUS伺服器，並負責執行返回的響應。

??? RADIUS?????? 伺服器負責接收使用者的串連請求，鑒別使用者，並為用戶端返回所有為使用者提供服務所必須的配置資訊。

??? 一個RADIUS伺服器可以為其他的RADIUS Server或其他種類證明伺服器擔當代理。

網路安全 (Network Security)

??? 用戶端和RADIUS伺服器之間的事務是通過使用一種從來不會在網上傳輸的共用機密進行鑒別的。另外，在用戶端和RADIUS伺服器之間的任何使用者密碼都是被加密後傳輸的，這是為了避免某些人在不安全的網路上監聽擷取使用者密碼的可能性。

靈活的認證機制 (Flexible Authentication Mechanisms)

??? ADIUS伺服器能支援多種認證使用者的方法。當使用者提供了使用者名稱和原始密碼後，RADIUS伺服器可以支援點對點的PAP認證（PPP PAP）、點對點的CHAP認證（PPP CHAP）、UNIX的登入操作（UNIX Login）、和其他認證機制。

擴充協議(Extensible Protocol)

所有事務由變長的屬性、長度和值，這樣的三元組組成。新屬性的值可以在不中斷已存在協議執行的前提下進行添加。

1.1要求術語的說明

???? 文中的關鍵字“必須”，“必須不”，“要求的”，“應該”，“不應該”，“會”，“不會”，“建議”，“或許”，“可選的”在這篇文檔中的解釋是和BCP 14 [2]中描述的意思是一樣。而且不管它們是否為大寫，它們所表述的意思都是一樣的。

??? 如果一項操作對它執行的協議不能滿足一個或多個必須條件或滿足了不可被滿足的條件，則此項操作不會被執行。一項操作對它要執行的協議滿足了所有“必須”，“必須不”，“應該”，“不應該”的必要條件，它被稱為“無條件服從”；一項操作對它要執行的協議滿足了所有“必須”，“必須不”必要條件，但沒有完全達到“會”，“不會”條件，則被稱為“有條件服從”。

一個不執行給定服務的網路接入伺服器（Network Access Server）一定沒有具備執行那項服務的RADIUS屬性。例如，一個不能提供Apple Talk 遠程接入協議（ARAP）服務的NAS伺服器一定沒有滿足執行ARAP服務RADIUS屬性。一個NAS?????? 伺服器一定會把一項在接入允許資料包中的不可實現的指定服務看作是收到了接入拒絕資料包。

1.2 術語

這篇文檔將會常用到以下術語：

服務????

網路接入伺服器對撥號接入的使用者提供的一種服務。例如，點對點傳輸，遠程登入。

會話

???? 每一個由NAS伺服器提供的給撥號使用者的服務由交談群組成，它的起始被定義為服務首

次被提供的那點，會話結束被定義為服務結束的那一點。在NAS伺服器支援的前提下，使用者可以有多個並行或串列的會話。

簡單丟棄

??? 這意味著執行操作沒有做進一步處理的能力，只是將資料包簡單的丟棄。該執行應該提

供記錄錯誤的能力，如丟棄包的內容；並在統計處記錄下該事件。

2. 運行

在一個用戶端被設定使用RADIUS協議後，任何使用這個終端的使用者都需要向這個用戶端提供認證資訊。此資訊或許以一種定製化的提示資訊出現，使用者需要輸入他們的使用者名稱和密碼。或許也可以選擇一種配置連線協定，比如像點對點的傳輸協議（Point-to-Point Protocol）,通過認證包來傳遞這種認證資訊。

一旦用戶端收到此類資訊，它會選擇使用RADIUS協議進行認證。之後，用戶端建立一個“接入請求”資料包，此包包含了諸如像使用者名稱、使用者密碼、客戶機ID、使用者正在訪問的連接埠編號。當密碼出現時，有一種基於RSA實驗室的資訊分類演算法（Message Digest Algorithm）MD5[3]的方法對其加密。

“接入請求”是通過網路提交給RADIUS伺服器。如果在一定長度的時間裡，伺服器沒有返迴響應資訊，請求會被重複傳輸許多次。在主伺服器故障或不能串連到的情況下，用戶端也可以繼續向一個或多個後備伺服器發出請求。後備伺服器在多次嘗試串連主伺服器失敗後，或在一輪迴圈方式結束後被選擇串連。重試和回退演算法是當前研究的課題，本文不對它做詳細說明。

一旦RADIUS伺服器收到請求資訊，它會對傳輸資訊的用戶端進行驗證。一個來自沒有和RADIUS伺服器具有共用機密的用戶端請求，該資料包會被簡單的丟棄。如果用戶端是合法的，RADIUS伺服器會查詢使用者資料庫找到這個使用者，把查詢到的使用者名稱同請求中的進行比較。資料庫中的使用者記錄包含了一組對使用者來說必須滿足的使用者接入條件，它不只是包含使用者的密碼驗證資訊，而且也可以指定允許接入的用戶端和連接埠號碼。

在為了滿足某個請求時，RADIUS伺服器也可以作為用戶端，向其他伺服器傳輸請求。

如果任何“代理程式狀態（Proxy-State）”屬性出現在接入請求資料包中，它們都必須在不做任何更改和保持原順序的前提下拷貝到響應資料包中。其他屬性可以放到“代理程式狀態（Proxy-State）”屬性的前面、後面甚至是中間。

如果有任何條件沒有得到滿足，RADIUS伺服器會發出一個“接入拒絕（Access-Reject）”響應，表示該使用者請求是無效的。如果要求的話，RADIUS伺服器可以在接入拒絕響應中包含簡訊，此簡訊可以通過用戶端顯示給使用者。除了代理程式狀態（Proxy-State）屬性外沒有任何其他屬性允許存在於接入拒絕（Access-Reject）響應中。

如果所有的條件被滿足而且伺服器會傳輸一個使用者必須響應的盤問，因此RADIUS伺服器會傳輸一個“接入盤問（Access Challenge）”響應。它或許會包含一個文本資訊，可以在使用者端向使用者顯示的響應提示，並可以包含一種狀態屬性。

如果用戶端收到接入盤問而且支援“盤問／響應（challenge/respond）”,如果有的話，它會向使用者顯示文本資訊，並提示使用者做出響應。然後，用戶端再次提交一個包含新請求號的源接入請求，並用加密響應代替使用者密碼屬性，如果有的話，還包括來自接入盤問的狀態屬性。狀態屬性應該僅有0或1兩個常數出現在一個請求中。伺服器可以用“接入接受（Access-Accept）”、“接入拒絕(Access-Reject)”或“接入盤問（Access-Challenge）”對這個新接入請求進行響應。

如果所有的條件都被滿足，使用者的配置值表被置於接入允許響應中。這些值包含了服務類型(如：串列線路介面協議(SLIP)，點對點傳輸協議(PPP)，登入使用者（Login User）)和交付要求服務的所有必須值。對串列線路介面協議（SLIP）和點對點傳輸協議（PPP）來說，這些值也許包括諸如IP地址、子網路遮罩、傳輸單元最大值（MTU），要求壓縮率和指定的包過濾標誌。對字元模式的使用者，這些值或許還包括請求的協議和主機。

2.1盤問／響應

??? 在盤問響應認證過程中，使用者被給予一個不可預知的數字，並要求對此數字加密後返回結果。已授權使用者裝備有特殊的裝置，如智慧卡或軟體，它們能不費力的計算出正確響應結果。沒有授權的使用者僅僅只能對響應進行猜測，因為他們缺少適當的裝置或軟體和必需的密鑰知識來類比此種裝置或軟體。

??? 接入盤問報文典型地包含一個回複資訊，此資訊中包括一個可以顯示給使用者的盤問，例如一個不可能被重複的數值。典型的情況是來自擴充伺服器，擴充伺服器是知道那一類鑒別碼對應這個已經被授權的使用者，因此能選擇一個適當基數和長度的隨機的或不重複的偽隨機數。

??? 使用者然後把這個盤問（不重複的數值）輸入到他的裝置或軟體中，並計算出一個響應值，使用者將此值輸入到用戶端，由用戶端通過第二個接入請求資料包把它提交給RADIUS伺服器。如果響應報文是與RADIUS伺服器預期的響應報文匹配，則伺服器會回送一個接入允許資料包，否則是回送接入拒絕資料包。

例如，網路接入伺服器傳輸一個接入請求資料包給RADIUS伺服器，包中包含網路接入伺服器的標識，網路接入伺服器的連接埠號碼，使用者名稱，使用者密碼（此密碼或許是一個像“challenge”似的固定字串，或者是被忽略的）。伺服器送回一個具有狀態和回複訊息的接入盤問資料包，其中回複訊息包含有 “challenge 12345678，在提示處輸入你的響應值”資訊，這幾行資訊可由接入伺服器顯示給使用者。網路接入伺服器（NAS）為這個響應提供提示資訊，傳輸一個新的接入請求給伺服器（用新的包編號），包括NAS標識、NAS連接埠號碼、使用者名稱、使用者密碼（剛才由使用者輸入的響應值，現在已經加密），和來自伺服器端接入盤問中相同的狀態屬性。根據判斷響應值是否與要求的值匹配，伺服器送回一個接入允許或接入拒絕資料包，或者甚至會傳輸另一個接入盤問資料包。

2.2 用不加密驗證和加密驗證配合動作

???? 對口令驗證協議（PAP），NAS採取了PAP ID和密碼，在一個接入請求包中將它們作為使用者名稱和使用者密碼傳輸出去。NAS可以包含服務類型屬性Attribute Service-Type＝ Framed-User，和Framed-Protocol＝PPP作為一個提示告訴RADIUS伺服器PPP服務是所希望的服務。

??? 對質詢握手身份認證協議（CHAP），NAS建立一個隨機質詢（最好是是16個位元組），然後把它傳輸給使用者，使用者返回一個帶有CHAP ID和CHAP使用者名稱的CHAP響應。NAS隨後傳輸一個請求接入資料包給RADIUS伺服器，該請求包中，CHAP使用者名稱稱替代了使用者名稱（User-Name）、CHAP ID和加密的響應值代替CHAP密碼（CHAP-Password）(屬性3 )。隨機質詢或者被包含在CHAP盤問（CHAP-Challenge）屬性中，或者如果它是16個位元組長，它可被放到接入請求資料包中的請求鑒別碼（Request Authenticator）域中。NAS可以包含Attribute Service-Type＝Framed-User，和Framed-Protocol＝PPP作為一個提示告訴RADIUS伺服器PPP服務是所希望的服務。

??? RADIUS伺服器根據使用者名稱檢查對應的密碼，加密盤問，用MD5演算法對CHAP ID位元組，前面找到的密碼和CHAP盤問（如果在CHAP盤問屬性存在則來自與此，否則來自請求認證者），把這個結果與CHAP密碼進行比較。如果它們是相匹配，伺服器送回一個接入允許資料包，否則送回一個接入拒絕資料包。

如果RADIUS伺服器不能執行被請求的認證，它一定返回一個接入拒絕資料包。例如，CHAP要求以明文方式給伺服器傳輸密碼，以便它能加密CHAP盤問並與CHAP響應相比較。如果不是以明文傳輸密碼，伺服器一定會給用戶端傳輸一個接入拒絕包。

2.3 代理

對RADIUSProxy 伺服器來說，一個RADIUS伺服器在收到一個來自RADIUS用戶端（例如NAS伺服器）的驗證請求（或者記賬請求）後，向一個遠端RADIUS伺服器提交該請求，收到來自遠程伺服器的回複後，將這個回複傳輸給客戶，這個回複可能帶有反映本地管理原則的變化。使用RADIUSProxy 伺服器通常是為了漫遊。漫遊功能使兩個或更多的管理實體允許每一個使用者為某項服務而撥入到任一個實體網路中。

??? NAS傳輸RADIUS接入請求給“轉送伺服器(forwarding server)”，轉送伺服器把這個請求轉送給“遠程伺服器(remote server)”。遠程伺服器送回一個響應（接入允許、接入拒絕、接入質詢）給轉送伺服器，轉送伺服器再把這個響應返回給NAS。對於RADIUS代理操作，使用者名稱屬性可以包含一個網路介面標識符[8]。哪一個伺服器應該接收轉送請求是根據認證域確定。認證域可以是網路介面標識符（指定的域）的一部分。或者，哪個伺服器接收轉送請求的選擇可以基於任何一種轉送伺服器指定使用的標準，例如“調用站編號(Called-Station Id)”。

??? 一個RADIUS伺服器可以同時作為轉送伺服器和遠程伺服器運行。在某些域中作為一個轉寄伺服器，在其他域中作為一個遠程伺服器。一個轉寄伺服器可以作為任何數量遠程伺服器的轉寄者。一個遠程伺服器可以有任意數量的轉寄伺服器向它轉寄，也能向任意數量域提供認證。一個轉寄伺服器可以向另一個轉寄伺服器轉寄，從而產生一個代理鏈，應當注意避免循環參考。

??? 下面解釋一個Proxy 伺服器在一個NAS伺服器、轉寄伺服器和遠程伺服器之間的通訊。

1．NAS向一個轉寄伺服器發出接入請求。

??? 2．轉寄伺服器把這個請求轉寄給一個遠程伺服器。

??? 3．遠程伺服器給轉寄伺服器送回接入允許、接入拒絕或接入盤問。在這個例子中，伺服器送回的是接入允許。

??? 4．轉寄伺服器將接入允許傳輸給NAS。

??? 轉寄伺服器必須把已經存在於資料包中的任何代理程式狀態屬性當作不可見的資料。它的操作禁止依靠被前面伺服器添加到代理程式狀態屬性中的內容

??? 如果收到來自用戶端的請求中有任何代理程式狀態屬性，在給用戶端的回複中，轉寄伺服器必須在給用戶端的回複中包括這些代理程式狀態屬性。當轉寄伺服器轉寄這個請求時，它可以把代理程式狀態屬性包含在其中，也可以在已轉寄的請求中忽略代理程式狀態屬性。如果轉寄伺服器在轉寄的接入請求中忽略了代理程式狀態屬性，它必須在響應返回給使用者之前把這些代理程式狀態屬性添加到該響應中。

??? 現在我們更為詳細地說明每一步。

??? 1．NAS傳輸它的接入請求給轉寄伺服器。如果使用者密碼存在，轉寄伺服器會用與NAS共有的金鑰組使用者密碼進行解密。如果在資料包中有一個CHAP密碼屬性存在，沒有CHAP盤問屬性存在，轉寄伺服器必須保證請求鑒別碼完整的情況下，或者把它拷貝到CHAP盤問屬性中。

??? 轉寄伺服器可以向資料包添加一個代理程式狀態屬性（只能添加一個）。如果它添加了代理程式狀態，該代理程式狀態只能出現在資料包中任何其他代理程式狀態屬性之後。轉寄伺服器禁止修改任何其他已經存在於資料包中的代理程式狀態屬性（轉寄伺服器可以選擇不轉寄它們，但一定不能對它們修改）。轉寄伺服器禁止改變包括代理程式狀態在內的同種類型任何屬性的順序。

??? 2．如果使用者密碼存在的話，轉寄伺服器用和遠程伺服器共有的金鑰組使用者密碼進行加密。它還會根據要求設定標識，向遠程伺服器轉寄接入請求。

??? 3．遠程伺服器（如果是最終目標伺服器）會使用使用者密碼、CHAP密碼或者是將來擴充時指定的一些方法驗證使用者的合法性，然後返回接入允許、接入拒絕或者接入盤問給轉寄伺服器。對於這個例子，遠程伺服器傳輸的是一個接入允許資料包，遠程伺服器必須按照原有的順序而且不做任何修改的情況下，把所有的代理程式狀態屬性從接入請求中拷貝到響應資料

包中。

4．轉寄伺服器使用它與遠程伺服器共有的金鑰組響應鑒別碼(ResponseAuthenticator）進行驗證，如果驗證失敗，它會簡單的將資料包丟棄。如果驗證通過，轉寄伺服器去掉最後的代理程式狀態（如果資料包內它附加過一個），使用它與NAS共有的密鑰簽發響應鑒別碼，恢複標識使它與NAS傳輸的源請求標識匹配，然後傳輸接入允許給NAS。

轉寄伺服器可能修改屬性以執行本地策略。關於這種策略的討論是在這篇文檔範圍之外，而且是受以下限制的。轉寄伺服器禁止修改資料包中存在的代理程式狀態、狀態或類別屬性。

2.4 為什麼使用UDP

???? 一個經常問到的問題是為什麼使用UDP而不是TCP作為傳輸協議。選擇UDP是基於嚴格的技術上的原因。

??? 這有許多必須被理解的論點。RADIUS是一個事務,基於幾個具有有趣特點的協議。

??? 1．如果向主驗證伺服器發出的請求失敗，則必須尋找待命伺服器。

??? 為了滿足這個要求，考慮到向待命伺服器傳輸請求，請求副本必須保留在傳輸層，意味著重發計時器仍然是需要的。

?2．這個特別協議的計時要求與TCP所提供的有較大的不同。

在一種極端的情況下，RADIUS不做遺失資料的響應檢查。使用者願意為完成驗證而等幾秒鐘。通常帶有侵略性的TCP中繼 (基於平均往返時間)是不需要的,TC確認P開銷也是不需要的。

? 在另一種極端情況下,使用者不願花幾分鐘等待驗證。因此兩分鐘後，可靠的TCP資料遞送也是無效的。對待命伺服器快速的使用能在使用者放棄之前獲得訪問。

? 3. 協議的無狀態特性簡化了UDP的使用

伺服器和客戶機不停變化。系統重新啟動，或單路供電。通常情況下，這不會產生問題，

但會導致出現逾時和TCP串連中斷檢測，通過編寫編碼能夠處理這類例外狀況事件。無論如何UDP完全消除了這類特殊處理以及其中的任何一部分。每一個伺服器和用戶端只需一次開啟他們UDP 傳輸，爾後可以使傳輸處於一種開啟的狀態，也許在網路上從始至終傳輸的是不成功資訊。

4.UDP簡化了伺服器的實現

在最早的RADIUS實現中，伺服器是單線程的。這意味著只能有一個請求被接收、處理和返回。隨後發現在後台安全機制會佔用即時時間（1秒或更多）的環境中這樣做是難管理的。伺服器的請求隊列會被填滿，在每分鐘內有成百上千的使用者正在等待驗證的環境中，請求的輪換時間會長於使用者所能忍受的等待時間，（尤其嚴重的是在資料庫中的一次特殊的尋找，或者花在DNS上的時間大於30秒的情況）。顯而易見的解決方案是多線程。用UDP解決這一問題是很簡單的。每一個請求得到一個單獨的進程，通過一個簡單的UDP資料包進行與用戶端原始通訊，從而達到與用戶端NAS直接響應的目的。

UDP並不是一副萬能藥。應當注意的是使用UDP需要一種內嵌於TCP的功能：使用UDP，我們必須通過人工成功管理聯絡同一台伺服器中繼計時器，但我們並不需要花費同樣的我們必須通過人工成功管理聯絡同一台伺服器中繼計時器，但我們並不需要花費同樣的注意力給TCP提供的計時器。這是在這個協議中以很小的代價換來UDP諸多優點的懲罰.

?沒有TCP我們仍然可能使用著金屬線串連的錫罐通訊。但是對於這個特殊的協議,UDP是一個更好的選擇。

2.5 中繼提示

如果RADIUS伺服器和副RADIUS伺服器擁有共用密鑰，在向待命伺服器轉寄資料包時用相同的ID和請求鑒別碼是可行的，因為屬性內容沒有發生變化。用一個新的請求鑒別碼向待命伺服器傳輸也是可以的。

如果你改變了使用者密碼屬性的內容（或者其他屬性），你需要一個新的請求鑒別碼，因此還需要一個新的ID。

如果NAS向一個與前一個伺服器完全相同的伺服器傳輸RADIUS請求，而且屬性內容沒有發生變化，你必須使用相同請求鑒別碼、ID、和源連接埠號碼。若出現屬性被修改，你必須使用新的請求鑒別碼和ID。

NAS可以在所有的伺服器中使用同一個ID，或者對每一個伺服器使用單獨的ID，這是根據使用者的要求決定。如果由於額外的請求，一個NAS需要多於256個ID，它可以使用額外的源連接埠號碼傳輸這些請求，並對每一個源連接埠ID進行跟蹤。這樣做，某一時刻對某一個伺服器的額外請求，上限大約是16，000，000。

2.6 保持啟用狀態應該考慮的損害

一些應用者已經採取傳輸測試的RADIUS請求給伺服器的方法，看伺服器是否處於啟用狀態。這種方法是不可取得，因為它會增加額外的負荷，而且因為沒有提供任何附加有用資訊，所以損害可測量性。因為一個RADIUS請求是包含在一個單獨的資料包中，在你送出ping 的這段時間裡，你或許可以傳輸一個RADIUS請求，得到一個RADIUS響應得知RADIUS伺服器處於啟用狀態。如果你沒有要傳輸的RADIUS請求，就不必關心伺服器是否處於啟用狀態，因為你沒有使用到它。

如果你想監視你的RADIUS伺服器，可以使用簡易網路管理通訊協定（SNMP），這是SNMP的指責所在。