RADIUS無效驗證器和消息驗證器故障排除指南

簡介

本檔案介紹RADIUS驗證器標頭和訊息驗證器屬性、使用方式以及預期驗證失敗的時間。

驗證器標頭

根據RFC 2865，驗證器標頭長度為16位元組。在訪問請求中使用時，它稱為請求驗證器。當它用於任何型別的響應時，它稱為響應驗證器。它用於：

• 響應驗證
• 密碼隱藏

響應驗證

如果伺服器使用正確的響應身份驗證器進行響應，則客戶端可以計算該響應是否與有效請求相關。

客戶端傳送帶有隨機身份驗證器標頭的請求。然後，傳送響應的伺服器將使用請求資料包以及共用金鑰來計算響應身份驗證器：

ResponseAuth = MD5(Code + ID + Length + RequestAuth + Attributes + Secret) 

接收響應的客戶端執行相同的操作。如果結果相同，則表示資料包正確。

附註：知道秘密值的攻擊者無法欺騙響應，除非它能夠嗅探請求。

何時會出現驗證失敗：

如果交換機不再快取請求（例如，由於超時），則會出現驗證失敗。 當共用金鑰無效時，您也會遇到此情況（yes - Access-Reject也包含此標頭）。 如此一來，網路存取裝置(NAD)便可偵測共用密碼不相符的情況。通常，身份驗證、授權和記帳(AAA)客戶端/伺服器會將其報告為共用金鑰不匹配，但不會顯示詳細資訊。

密碼隱藏

身份驗證器標頭也用於避免以純文字檔案格式傳送User-Password屬性。首先計算消息摘要5(MD5 - secret， authenticator)。然後執行多個帶有密碼塊的XOR操作。此方法容易受到離線攻擊（彩虹表），因為MD5不再被視為一個強大的單向演算法。

以下是用於計算使用者密碼的Python指令碼：

def Encrypt_Pass(password, authenticator, secret):
        m = md5()
        m.update(secret+authenticator)
        return "".join(chr(ord(x) ^ ord(y)) for x, y in zip(password.ljust
       (16,'\0')[:16], m.digest()[:16]))

重新傳輸

如果RADIUS Access-Request中的任何屬性已更改（例如RADIUS ID、使用者名稱等），則必須生成新的Authenticator欄位，並且必須重新計算依賴該欄位的所有其他欄位。如果這是重新傳輸，則不會發生任何變化。

計量

Access-Request和Accounting-Request的Authenticator Header含義不同。

對於Access-Request，Authenticator是隨機生成的，它需要接收響應，並且ResponseAuthenticator計算正確，這證明了響應與該特定請求相關。

對於Accounting-Request，Authenticator不是隨機的，但它是計算的（根據RFC 2866）：

RequestAuth = MD5(Code + ID + Length + 16 zero octets + Attributes + Secret) 

這樣，如果重新計算的值與Authenticator值不匹配，伺服器可以立即檢查記帳消息並丟棄資料包。身份服務引擎(ISE)返回：

11038 RADIUS Accounting-Request header contains invalid Authenticator field

此問題的典型原因是共用金鑰不正確。

Message-Authenticator屬性

Message-Authenticator屬性是在RFC 3579中定義的RADIUS屬性。其用途類似：進行簽名和驗證。但這一次，它不是用於驗證響應，而是用於驗證請求。

傳送存取要求的使用者端（也可以是回應Access-Challenge的伺服器）會根據自己的封包計算基於雜湊的訊息驗證碼(HMAC)-MD5，然後新增訊息驗證器屬性作為簽名。然後，伺服器可以驗證它是否執行了相同的操作。

此公式類似於身份驗證器標頭：

Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator,
Attributes)

HMAC-MD5函式有兩個引數：

• 資料包的負載，包括用零填充的16位元組消息驗證器欄位
• 共用金鑰

何時使用消息驗證器：

每個資料包都必須使用消息驗證器，包括可擴展身份驗證協定(EAP)消息(RFC 3579)。 這包括傳送訪問請求的客戶端和使用Access-Challenge進行響應的伺服器。如果驗證失敗，另一端會以靜默方式丟棄資料包。

何時會出現驗證失敗：

當共用金鑰無效時，驗證失敗。然後，AAA伺服器無法驗證請求。

ISE報告：

11036 The Message-Authenticator Radius Attribute is invalid.

這通常發生於附加EAP消息的較後階段。802.1x作業階段的首個RADIUS封包不包括EAP訊息；沒有Message-Authenticator欄位，並且無法驗證請求，但在此階段，客戶端能夠使用Authenticator欄位驗證響應。

驗證Message-Authenticator屬性

以下範例顯示如何手動計數值，以確保正確計算值。

已選擇資料包編號30(Access-Request)。它位於EAP會話的中間，資料包包括Message-Authenticator欄位。目的是驗證Message-Authenticator是正確的：

1. 按一下右鍵Radius Protocol，然後選擇Export selected packet bytes。
   
   
2. 將RADIUS負載寫入檔案（二進位制資料）。
   
   
3. 要計算Message-Authenticator欄位，必須在該欄位中放置零並計算HMAC-MD5。
   
   例如，當您在鍵入「：%!xxd」之後使用十六進位制/二進位制編輯器（如vim）時，該編輯器將切換到十六進位制模式，從「5012」之後開始將零設定為16個位元組(50hex在十進位制中為80，該十進位制是消息驗證器型別，12是包含屬性值對(AVP)標頭的大小為18):
   
   請注意，Vim和其他文本編輯器可以在儲存時向檔案末尾新增一個額外的LineFeed字元（十六進製為「0a」）。確保使用文本編輯器（vim -b檔案）的二進位制模式來防止LineFeed字元出現。 
   
   

   

   
   在修改之後，負載準備就緒。必須返回到十六進位制/二進位制模式(型別：":%!xxd -r")並儲存檔案(":wq")。 您可以仔細檢查是否利用「hexdump -C file」新增了額外的LineFeed字元。 
   
   
4. 使用OpenSSL來計算HMAC-MD5:
   
   

   pluton # cat packet30-clear-msgauth.bin | openssl dgst -md5 -hmac 'cisco'
   (stdin)= 01418d3b1865556918269d3cf73608b0

   
   
   HMAD-MD5函式有兩個引數：標準輸入(stdin)中的第一個是消息本身，第二個是共用金鑰（本例中為Cisco）。 結果與附加到RADIUS訪問請求資料包的消息驗證器的值完全相同。

使用Python指令碼可以計算相同內容：

 Python 2:

pluton # cat hmac.py 
#!/usr/bin/env python

import base64
import hmac
import hashlib

f = open('packet30-clear-msgauth.bin', 'rb')
try:
    body = f.read()
finally:
    f.close()

digest = hmac.new('cisco', body, hashlib.md5)
d=digest.hexdigest()
print d

pluton # python hmac.py 
01418d3b1865556918269d3cf73608b0

Python 3:

import hmac
import hashlib

with open('packet30-clear-msgauth.bin', 'rb') as f:
    body = f.read()

digest = hmac.new(b'cisco', body, hashlib.md5)
print(digest.hexdigest())

上例展示如何從Access-Request計算Message-Authenticator欄位。對於Access-Challenge、Access-Accept和Access-Reject，邏輯完全相同，但必須記住必須使用請求驗證器，這是前面的Access-Request資料包中提供的。

相關資訊

• RFC 2865
• RFC 2866
• RFC 3579
• 技術支援與文件 - Cisco Systems