2.3 Proxy

2.3. Proxy

Mit Proxy-RADIUS empfängt ein RADIUS-Server eine Authentifizierungs- (oder Accounting-) Anfrage von einem RADIUS-Client (wie einem NAS), leitet die Anfrage an einen entfernten RADIUS-Server weiter, empfängt die Antwort vom entfernten Server und sendet diese Antwort an den Client, möglicherweise mit Änderungen, um lokale administrative Richtlinien widerzuspiegeln. Eine häufige Verwendung für Proxy-RADIUS ist Roaming. Roaming ermöglicht es zwei oder mehr administrativen Einheiten, den Benutzern der jeweils anderen Einheit den Einwahlzugriff auf das Netzwerk einer der beiden Einheiten zu gewähren.

Der NAS sendet seinen RADIUS-Access-Request an den "Forwarding Server" (Weiterleitungsserver), der ihn an den "Remote Server" (entfernten Server) weiterleitet. Der Remote Server sendet eine Antwort (Access-Accept, Access-Reject oder Access-Challenge) zurück an den Forwarding Server, der sie an den NAS zurücksendet. Das User-Name-Attribut KANN einen Network Access Identifier [8] für RADIUS-Proxy-Operationen enthalten. Die Wahl, welcher Server die weitergeleitete Anfrage erhält, SOLLTE auf dem Authentifizierungs-"Realm" basieren. Das Authentifizierungs-Realm KANN der Realm-Teil eines Network Access Identifiers sein (ein "benanntes Realm"). Alternativ KANN die Wahl, welcher Server die weitergeleitete Anfrage erhält, auf anderen Kriterien basieren, für die der Forwarding Server konfiguriert ist, wie z.B. Called-Station-Id (ein "nummeriertes Realm").

Ein RADIUS-Server kann sowohl als Forwarding Server als auch als Remote Server fungieren und als Forwarding Server für einige Realms und als Remote Server für andere Realms dienen. Ein Forwarding Server kann als Weiterleiter für beliebig viele Remote Server fungieren. Ein Remote Server kann beliebig viele Server haben, die an ihn weiterleiten, und kann Authentifizierung für beliebig viele Realms bereitstellen. Ein Forwarding Server kann an einen anderen Forwarding Server weiterleiten, um eine Kette von Proxies zu erstellen, obwohl darauf geachtet werden muss, keine Schleifen einzuführen.

Das folgende Szenario veranschaulicht eine Proxy-RADIUS-Kommunikation zwischen einem NAS und den Forwarding- und Remote-RADIUS-Servern:

1. Ein NAS sendet seinen Access-Request an den Forwarding Server.

2. Der Forwarding Server leitet den Access-Request an den Remote Server weiter.

3. Der Remote Server sendet ein Access-Accept, Access-Reject oder Access-Challenge zurück an den Forwarding Server. Für dieses Beispiel wird ein Access-Accept gesendet.

4. Der Forwarding Server sendet das Access-Accept an den NAS.

Der Forwarding Server MUSS alle Proxy-State-Attribute, die bereits im Paket vorhanden sind, als opake Daten behandeln. Seine Funktionsweise DARF NICHT vom Inhalt der Proxy-State-Attribute abhängen, die von vorherigen Servern hinzugefügt wurden.

Wenn Proxy-State-Attribute in der vom Client empfangenen Anfrage vorhanden sind, MUSS der Forwarding Server diese Proxy-State-Attribute in seine Antwort an den Client einfügen. Der Forwarding Server KANN die Proxy-State-Attribute in den Access-Request einfügen, wenn er die Anfrage weiterleitet, oder KANN sie in der weitergeleiteten Anfrage weglassen. Wenn der Forwarding Server die Proxy-State-Attribute in der weitergeleiteten Access-Request weglässt, MUSS er sie an die Antwort anhängen, bevor er sie an den Client sendet.

Wir untersuchen nun jeden Schritt detaillierter.

1. Ein NAS sendet seinen Access-Request an den Forwarding Server. Der Forwarding Server entschlüsselt das User-Password, falls vorhanden, unter Verwendung des gemeinsamen Geheimnisses, das er für den NAS kennt. Wenn ein CHAP-Password-Attribut im Paket vorhanden ist und kein CHAP-Challenge-Attribut vorhanden ist, MUSS der Forwarding Server den Request-Authenticator unverändert lassen oder ihn in ein CHAP-Challenge-Attribut kopieren.

2. Der Forwarding Server KANN ein Proxy-State-Attribut zum Paket hinzufügen. (Er DARF NICHT mehr als eines hinzufügen.) Wenn er ein Proxy-State hinzufügt, MUSS das Proxy-State nach allen anderen Proxy-States im Paket erscheinen. Der Forwarding Server DARF NICHT andere Proxy-States modifizieren, die im Paket waren (er kann wählen, sie nicht weiterzuleiten, aber er DARF NICHT deren Inhalt ändern). Der Forwarding Server DARF NICHT die Reihenfolge von Attributen desselben Typs ändern, einschließlich Proxy-State.

3. Der Forwarding Server verschlüsselt das User-Password, falls vorhanden, unter Verwendung des Geheimnisses, das er mit dem Remote Server teilt, setzt den Identifier nach Bedarf und leitet den Access-Request an den Remote Server weiter.

4. Der Remote Server (wenn er das endgültige Ziel ist) verifiziert den Benutzer mit User-Password, CHAP-Password oder einer solchen Methode, wie zukünftige Erweiterungen vorschreiben können, und gibt ein Access-Accept, Access-Reject oder Access-Challenge an den Forwarding Server zurück. Für dieses Beispiel wird ein Access-Accept gesendet. Der Remote Server MUSS alle Proxy-State-Attribute (und nur die Proxy-State-Attribute) in der Reihenfolge aus dem Access-Request in das Antwortpaket kopieren, ohne sie zu modifizieren.

5. Der Forwarding Server verifiziert den Response Authenticator unter Verwendung des Geheimnisses, das er mit dem Remote Server teilt, und verwirft das Paket stillschweigend, wenn die Verifizierung fehlschlägt. Wenn das Paket die Verifizierung besteht, entfernt der Forwarding Server das letzte Proxy-State (falls er eines angehängt hat), signiert den Response Authenticator unter Verwendung des Geheimnisses, das er mit dem NAS teilt, stellt den Identifier wieder her, um mit dem in der ursprünglichen Anfrage vom NAS übereinzustimmen, und sendet das Access-Accept an den NAS.

Ein Forwarding Server KANN Attribute modifizieren müssen, um lokale Richtlinien durchzusetzen. Eine solche Richtlinie liegt außerhalb des Umfangs dieses Dokuments, mit den folgenden Einschränkungen. Ein Forwarding Server DARF NICHT vorhandene Proxy-State-, State- oder Class-Attribute im Paket modifizieren.

Implementierer von Forwarding Servern sollten sorgfältig überlegen, welche Werte sie für Service-Type akzeptieren möchten. Sorgfältige Überlegung muss den Auswirkungen der Weitergabe von Service-Types von NAS-Prompt oder Administrative in einem proxierten Access-Accept gewidmet werden, und Implementierer möchten möglicherweise Mechanismen bereitstellen, um diese oder andere Service-Typen oder andere Attribute zu blockieren. Solche Mechanismen liegen außerhalb des Umfangs dieses Dokuments.