RADIUS: Handbuch zur Fehlerbehebung für ungültige Authentifizierer und Nachrichtenauthentifizierer

Einleitung

In diesem Dokument werden der RADIUS Authenticator-Header und das Message-Authenticator-Attribut beschrieben, wie sie verwendet werden und wann ein Validierungsfehler zu erwarten ist.

Authentifizierer-Header

Gemäß RFC 2865 ist der Authenticator-Header 16 Byte lang. Wenn es in einer Access-Anforderung verwendet wird, wird es als Request Authenticator bezeichnet. Wenn es in einer beliebigen Antwort verwendet wird, wird es als Response Authenticator (Antwortauthentifizierer) bezeichnet. Es wird verwendet für:

• Authentifizierung der Antwort
• Ausblenden von Kennwörtern

Authentifizierung der Antwort

Wenn der Server mit dem richtigen Response Authenticator antwortet, kann der Client berechnen, ob die Antwort mit einer gültigen Anfrage in Zusammenhang steht.

Der Client sendet die Anforderung mit dem Header für den zufälligen Authentifizierer. Anschließend berechnet der Server, der die Antwort sendet, den Response Authenticator unter Verwendung des Anforderungspakets zusammen mit dem gemeinsamen geheimen Schlüssel:

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

Der Client, der die Antwort empfängt, führt den gleichen Vorgang aus. Wenn das Ergebnis dasselbe ist, ist das Paket richtig.

Anmerkung: Der Angreifer, der den geheimen Wert kennt, kann die Antwort nur manipulieren, wenn er in der Lage ist, an der Anforderung zu schnüffeln.

Wann ein Validierungsfehler zu erwarten ist:

Ein Validierungsfehler tritt auf, wenn der Switch die Anforderung nicht mehr zwischenspeichert (z. B. aufgrund eines Timeouts). Sie können es auch erleben, wenn der gemeinsame geheime Schlüssel ungültig ist (ja - Access-Reject enthält auch diesen Header). Auf diese Weise kann das Netzwerkzugriffsgerät (Network Access Device, NAD) die Diskrepanz zwischen gemeinsam genutzten und geheimen Schlüsseln erkennen. In der Regel wird dies von AAA-Clients (Authentication, Authorization, and Accounting)/Servern als nicht übereinstimmender gemeinsamer Schlüssel gemeldet, die Details werden jedoch nicht angezeigt.

Ausblenden von Kennwörtern

Der Authentifizierer-Header wird auch verwendet, um das Senden des User-Password-Attributs im Nur-Text-Format zu vermeiden. Zuerst wird der Message Digest 5 (MD5 - geheim, Authentifikator) berechnet. Anschließend werden mehrere XOR-Operationen mit den Segmenten des Passworts ausgeführt. Diese Methode ist anfällig für Offline-Angriffe (Regenbogentabellen), da MD5 nicht mehr als starker Einweg-Algorithmus wahrgenommen wird.

Das folgende Python-Skript berechnet das Benutzerkennwort:

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]))

Erneute Übertragungen

Wenn eines der Attribute in der RADIUS-Zugriffsanforderung geändert wurde (z. B. RADIUS-ID, Benutzername usw.), muss das neue Authentifiziererfeld generiert und alle anderen davon abhängigen Felder neu berechnet werden. Wenn es sich um eine erneute Übertragung handelt, ändert sich nichts.

Buchhaltung

Die Bedeutung des Authenticator-Headers unterscheidet sich bei einer Access-Request und einer Accounting-Request.

Bei einer Access-Anforderung wird der Authenticator zufällig generiert, und es wird erwartet, dass er eine Antwort mit dem korrekt berechneten ResponseAuthenticator erhält, was beweist, dass die Antwort mit dieser spezifischen Anforderung in Beziehung stand.

Für eine Buchhaltungsanforderung ist der Authentifikator nicht zufällig, sondern wird (gemäß RFC 2866) berechnet:

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

Auf diese Weise kann der Server die Accounting-Nachricht sofort überprüfen und das Paket verwerfen, wenn der neu berechnete Wert nicht mit dem Authenticator-Wert übereinstimmt. Die Identity Services Engine (ISE) gibt Folgendes zurück:

11038 RADIUS Accounting-Request header contains invalid Authenticator field

Der typische Grund dafür ist der falsche gemeinsame geheime Schlüssel.

Message-Authenticator-Attribut

Das Message-Authenticator-Attribut ist das in RFC 3579 definierte RADIUS-Attribut. Es wird für einen ähnlichen Zweck verwendet: zum Signieren und Validieren. Diesmal wird es jedoch nicht verwendet, um eine Antwort, sondern eine Anfrage zu validieren.

Der Client, der eine Access-Request sendet (es kann sich auch um einen Server handeln, der mit einer Access-Challenge antwortet), berechnet den Hash-Based Message Authentication Code (HMAC)-MD5 aus seinem eigenen Paket und fügt dann das Message-Authenticator-Attribut als Signatur hinzu. Anschließend kann der Server überprüfen, ob er den gleichen Vorgang durchführt.

Die Formel ähnelt dem Authentifizierer-Header:

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

Die HMAC-MD5-Funktion verwendet zwei Argumente:

• Die Nutzlast des Pakets, die das 16 Byte lange Message-Authenticator-Feld mit Nullen enthält
• Das gemeinsame Geheimnis

Verwendung des Message-Authenticator:

Der Message-Authenticator muss für jedes Paket verwendet werden, das die Extensible Authentication Protocol (EAP)-Nachricht (RFC 3579) enthält. Dies umfasst sowohl den Client, der die Access-Request sendet, als auch den Server, der mit der Access-Challenge antwortet. Die andere Seite verwirft das Paket automatisch, wenn die Validierung fehlschlägt.

Wann ein Validierungsfehler zu erwarten ist:

Der Validierungsfehler tritt auf, wenn der gemeinsame geheime Schlüssel ungültig ist. In diesem Fall kann der AAA-Server die Anforderung nicht validieren.

Die ISE berichtet:

11036 The Message-Authenticator Radius Attribute is invalid.

Dies geschieht in der Regel zu einem späteren Zeitpunkt, wenn die EAP-Nachricht angefügt wird. Das erste RADIUS-Paket der 802.1x-Sitzung enthält nicht die EAP-Nachricht. Es gibt kein Feld für den Nachrichtenauthentifizierer, und es ist nicht möglich, die Anforderung zu überprüfen. Zu diesem Zeitpunkt kann der Client jedoch die Antwort mithilfe des Felds für den Authentifizierer validieren.

Überprüfen des Message-Authenticator-Attributs

Im folgenden Beispiel wird veranschaulicht, wie Sie den Wert manuell zählen, um sicherzustellen, dass er richtig berechnet wird.

Paket Nr. 30 (Access-Request) wurde ausgewählt. Es befindet sich mitten in der EAP-Sitzung, und das Paket enthält das Feld Message-Authenticator (Nachrichtenauthentifizierer). Das Ziel besteht darin, die Richtigkeit des Message-Authenticators zu überprüfen:

1. Klicken Sie mit der rechten Maustaste auf Radius Protocol, und wählen Sie Ausgewählte Paketbytes exportieren aus.
   
   
2. Schreiben Sie diese RADIUS-Nutzlast in eine Datei (Binärdaten).
   
   
3. Um das Message-Authenticator-Feld zu berechnen, müssen Sie Nullen eingeben und den HMAC-MD5 berechnen.
   
   Wenn Sie beispielsweise den Hex-/Binär-Editor (z. B. vim) verwenden, nachdem Sie ":%!xxd" eingegeben haben, der in den Hex-Modus wechselt und nach "5012" auf 16 Byte Nullen setzt (50hex ist 80 in dec, was Message-Authenticator-Typ ist, und 12 ist die Größe von 18 einschließlich des Attributwert-Paars (AVP)-Headers):
   
   Bitte beachten Sie, dass vim und andere Text-Editoren beim Speichern am Ende der Datei ein zusätzliches LineFeed-Zeichen ('0a' in Hex) hinzufügen können. Verwenden Sie den Binärmodus des Texteditors (vim -b-Datei), um zu verhindern, dass das Zeichen LineFeed angezeigt wird. 
   
   

   

   
   Nach dieser Änderung ist die Nutzlast bereit. Es ist notwendig, zum Hex-/Binärmodus zurückzukehren (Typ: ":%!xxd -r"), und speichern Sie die Datei (":wq"). Sie können überprüfen, ob ein zusätzliches LineFeed-Zeichen nicht durch Verwendung von 'hexdump -C file' hinzugefügt wurde. 
   
   
4. Verwenden Sie OpenSSL, um HMAC-MD5 zu berechnen:
   
   

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

   
   
   Die HMAD-MD5-Funktion verwendet zwei Argumente: Die erste Nachricht von der Standardeingabe (stdin) ist die Nachricht selbst und die zweite Nachricht ist der gemeinsame geheime Schlüssel (in diesem Beispiel Cisco). Das Ergebnis entspricht exakt dem Wert des Message-Authenticator, der an das RADIUS Access-Request-Paket angeschlossen ist.

Dasselbe kann mit dem Python-Skript berechnet werden:

 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())

Im vorherigen Beispiel wird veranschaulicht, wie das Feld Message-Authenticator aus der Access-Request berechnet wird. Bei "Access-Challenge", "Access-Accept" und "Access-Reject" ist die Logik exakt dieselbe, aber es ist wichtig, daran zu denken, dass "Request Authenticator" verwendet werden muss, was im vorherigen "Access-Request"-Paket enthalten ist.

Zugehörige Informationen

• RFC 2865
• RFC 2866
• RFC 3579
• Technischer Support und Dokumentation für Cisco Systeme