3. Packet Format (Paketformat)
3. Packet Format (Paketformat)
Genau ein RADIUS-Paket ist im UDP-Data-Feld [4] gekapselt, wobei das UDP-Destination-Port-Feld 1812 (dezimal) angibt.
Wenn eine Antwort generiert wird, werden Quell- und Zielports vertauscht.
Dieses Dokument dokumentiert das RADIUS-Protokoll. Die frühe Bereitstellung von RADIUS erfolgte unter Verwendung der UDP-Portnummer 1645, die mit dem "datametrics"-Dienst kollidiert. Die offiziell zugewiesene Portnummer für RADIUS ist 1812.
Eine Zusammenfassung des RADIUS-Datenformats ist unten dargestellt. Die Felder werden von links nach rechts übertragen.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
Das Code-Feld ist ein Oktett und identifiziert den Typ des RADIUS-Pakets. Wenn ein Paket mit einem ungültigen Code-Feld empfangen wird, wird es stillschweigend verworfen.
RADIUS-Codes (dezimal) werden wie folgt zugewiesen:
1 Access-Request
2 Access-Accept
3 Access-Reject
4 Accounting-Request
5 Accounting-Response
11 Access-Challenge
12 Status-Server (experimental)
13 Status-Client (experimental)
255 Reserved
Die Codes 4 und 5 werden im RADIUS-Accounting-Dokument [5] behandelt. Die Codes 12 und 13 sind für mögliche Verwendung reserviert, werden hier aber nicht weiter erwähnt.
Identifier
Das Identifier-Feld ist ein Oktett und hilft beim Abgleich von Anfragen und Antworten. Der RADIUS-Server kann eine doppelte Anfrage erkennen, wenn sie dieselbe Client-Quell-IP-Adresse, denselben Quell-UDP-Port und denselben Identifier innerhalb einer kurzen Zeitspanne hat.
Length
Das Length-Feld besteht aus zwei Oktetten. Es gibt die Länge des Pakets einschließlich der Felder Code, Identifier, Length, Authenticator und Attribute an. Oktette außerhalb des Bereichs des Length-Felds MÜSSEN als Padding behandelt und beim Empfang ignoriert werden. Wenn das Paket kürzer ist als das Length-Feld angibt, MUSS es stillschweigend verworfen werden. Die Mindestlänge beträgt 20 und die Maximallänge beträgt 4096.
Authenticator
Das Authenticator-Feld besteht aus sechzehn (16) Oktetten. Das höchstwertige Oktett wird zuerst übertragen. Dieser Wert wird verwendet, um die Antwort vom RADIUS-Server zu authentifizieren und wird im Passwort-Hiding-Algorithmus verwendet.
Request Authenticator
In Access-Request-Paketen ist der Authenticator-Wert eine 16-Oktett-Zufallszahl, genannt Request Authenticator. Der Wert SOLLTE unvorhersehbar und einzigartig über die Lebensdauer eines Geheimnisses (des zwischen Client und RADIUS-Server geteilten Passworts) sein, da die Wiederholung eines Request-Werts in Verbindung mit demselben Geheimnis es einem Angreifer ermöglichen würde, mit einer zuvor abgefangenen Antwort zu antworten. Da erwartet wird, dass dasselbe Geheimnis zur Authentifizierung mit Servern in unterschiedlichen geografischen Regionen verwendet werden KANN, SOLLTE das Request-Authenticator-Feld globale und zeitliche Einzigartigkeit aufweisen.
Der Request-Authenticator-Wert in einem Access-Request-Paket SOLLTE auch unvorhersehbar sein, damit ein Angreifer einen Server nicht dazu verleiten kann, auf eine vorhergesagte zukünftige Anfrage zu antworten, und dann die Antwort zu verwenden, um sich als dieser Server gegenüber einer zukünftigen Access-Request auszugeben.
Obwohl Protokolle wie RADIUS nicht in der Lage sind, gegen den Diebstahl einer authentifizierten Sitzung durch Echtzeit-Abhörangriffe zu schützen, kann die Generierung eindeutiger unvorhersehbarer Anfragen gegen eine breite Palette aktiver Angriffe auf die Authentifizierung schützen.
Der NAS und der RADIUS-Server teilen sich ein Geheimnis. Dieses gemeinsame Geheimnis, gefolgt vom Request Authenticator, wird durch einen Einweg-MD5-Hash geleitet, um einen 16-Oktett-Digest-Wert zu erzeugen, der mit dem vom Benutzer eingegebenen Passwort XOR-verknüpft wird, und das XOR-Ergebnis wird im User-Password-Attribut im Access-Request-Paket platziert. Siehe den Eintrag für User-Password im Abschnitt über Attribute für eine detailliertere Beschreibung.
Response Authenticator
Der Wert des Authenticator-Felds in Access-Accept-, Access-Reject- und Access-Challenge-Paketen wird Response Authenticator genannt und enthält einen Einweg-MD5-Hash, der über einen Strom von Oktetten berechnet wird, bestehend aus: dem RADIUS-Paket, beginnend mit dem Code-Feld, einschließlich des Identifiers, der Length, des Request-Authenticator-Felds aus dem Access-Request-Paket und den Response-Attributen, gefolgt vom gemeinsamen Geheimnis. Das heißt, ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret), wobei + die Verkettung bezeichnet.
Administrativer Hinweis
Das Geheimnis (zwischen dem Client und dem RADIUS-Server geteiltes Passwort) SOLLTE mindestens so groß und schwer zu erraten sein wie ein gut gewähltes Passwort. Es wird bevorzugt, dass das Geheimnis mindestens 16 Oktette umfasst. Dies soll einen ausreichend großen Bereich für das Geheimnis gewährleisten, um Schutz gegen erschöpfende Suchangriffe zu bieten. Das Geheimnis DARF NICHT leer sein (Länge 0), da dies es ermöglichen würde, Pakete trivial zu fälschen.
Ein RADIUS-Server MUSS die Quell-IP-Adresse des RADIUS-UDP-Pakets verwenden, um zu entscheiden, welches gemeinsame Geheimnis verwendet werden soll, damit RADIUS-Anfragen über Proxy weitergeleitet werden können.
Bei Verwendung eines Forwarding-Proxys muss der Proxy in der Lage sein, das Paket zu ändern, während es in jede Richtung durchläuft - wenn der Proxy die Anfrage weiterleitet, KANN der Proxy ein Proxy-State-Attribut hinzufügen, und wenn der Proxy eine Antwort weiterleitet, MUSS er sein Proxy-State-Attribut entfernen, falls er eines hinzugefügt hat. Proxy-State wird immer nach allen anderen Proxy-States hinzugefügt oder entfernt, aber es können keine anderen Annahmen über seine Position innerhalb der Liste der Attribute getroffen werden. Da Access-Accept- und Access-Reject-Antworten auf dem gesamten Paketinhalt authentifiziert werden, macht das Entfernen des Proxy-State-Attributs die Signatur im Paket ungültig - daher muss der Proxy es neu signieren.
Weitere Details zur RADIUS-Proxy-Implementierung liegen außerhalb des Umfangs dieses Dokuments.