Abrechnung im Hintergrund

Inhaltsverzeichnis

Dass Radius meist im Spiel ist, wenn man sich per Modem, ISDN oder DSL mit dem Internet verbindet, dürfte weitgehend unbekannt sein. Doch mit Hilfe dieses Verfahrens fällt die Entscheidung, ob und wie der ISP den Internetzugang gewährt. Zudem spielt Radius eine wichtige Rolle bei der Erfassung der Leistungsdaten für die spätere Berechnung.

Das muss den Administrator eines Firmennetzes natürlich nicht interessieren. Aber mittlerweile ist Radius aus einem ganz anderen Grund wichtig geworden: die Sicherheitsmechanismen von WLANs, WPA respektive WPA2, setzen bei größeren Installationen einen Radius-Server im Hintergrund voraus. Denn Radius ist flexibel genug, um für drahtlose und drahtgebundene Netze eingesetzt werden zu können.

Authentifizierung und Autorisierung

Radius steht für „Remote Authentication Dial In User Service“ und ist aktuell in den RFCs 2865 und 2866 vom Juni 2000 beschrieben. Diese Auflösung drückt die umfassenden Möglichkeiten des Protokolls nur zum Teil aus, denn neben „Authentication“ (Authentifizierung) widmet sich Radius den Themen „Authorization“ (Autorisierung) und „Accounting“ (Abrechnung), den drei Aufgaben also, die gern zum Kürzel AAA (sprich: triple A) zusammengefasst werden.

Authentifizierung und Autorisierung sind, obwohl häufig in einen Topf geworfen, unterschiedliche Dinge. Bei der Authentifizierung geht es darum, festzustellen, ob der Benutzer tatsächlich derjenige ist, für den er sich ausgibt. Hier kommen verschiedene Methoden wie eine Benutzername-Passwort-Überprüfung oder Ähnliches zum Einsatz. Auf welche Dienste und Leistungen der Benutzer tatsächlich zugreifen darf, welche Rechte er eingeräumt bekommt, das festzulegen, ist Aufgabe der Autorisierung. Darf der Kunde den Zugang momentan überhaupt benutzen? Vielleicht ist die letzte Rechnung nicht bezahlt, oder der Vertrag berechtigt nur zur Nutzung zu bestimmten Zeiten. Bekommt er eine feste IP-Adresse? Hat er Zugriff auf Mehrwertdienste? All dies ist Gegenstand der Autorisierung.

Bleibt die Aufgabe der Abrechnung. Hieran haben Provider meist ein besonderes Interesse; vielleicht werden Zugriffsminuten gezählt, vielleicht auch das Übertragungsvolumen. Auch hier ist Radius hilfreich und bietet geeignete Mechanismen an.

Verschiedene Ports im Gebrauch

Radius ist ein Client-Server-Protokoll. Die Kommunikation zwischen Client und Server läuft über UDP-Datagramme. Es wird bewusst keine gesicherte TCP-Verbindung genutzt, wie auch insgesamt das ganze Protokoll „statusfrei“ (stateless) ist. Der Radius-Client (z. B. ein NAS) schickt eine Anfrage an den Radius-Server, dieser prüft sie und antwortet. Erhält der Client innerhalb einer festgelegten Zeit keine Antwort, wiederholt er seine Anfrage.

Für die Kommunikation mit einem Radius-Server sind in den RFCs die UDP-Ports 1812 (Authentication) und 1813 (Accounting) festgelegt. Häufig sind auch noch die Ports 1645 und 1646 im Einsatz. Diese entsprechen der ursprünglichen Radius-Spezifikation; nachträglich stellte sich aber heraus, dass diese Portnummern bereits anderweitig vergeben waren. Wenn man mit einem Radius-Server Kommunikationsprobleme hat, sollte man darum als Erstes klären, auf welchem Port er angesprochen werden möchte.

Client und Server vereinbaren vorab ein „Shared Secret“, zum einen, um Informationen verschlüsselt auszutauschen, vor allem aber, um die Antwort des Radius-Servers zu authentisieren. Klappt die Kommunikation zwischen Client und Server nicht, sollte man prüfen, ob beide Seiten dasselbe Shared Secret benutzen. Es sollte sich dabei übrigens nicht um ein kurzes Klartextkennwort handeln, sondern um eine hinreichend lange, komplizierte Zeichenfolge, die in keinem Wörterbuch zu finden ist.

Wer ganz sicher gehen will, kann ein Tool benutzen, das der Radius-Server-Hersteller Funk auf seiner Website zum kostenlosen Download bereit hält. Dieser „Password Amplifier“ erzeugt aus einem (hoffentlich schon recht guten) Passwort durch Hash-Operationen eine kryptische Zeichenfolge. Dasselbe Passwort liefert immer dieselbe Zeichenfolge, man merkt sich also das Ursprungspasswort, verwendet aber den generierten String. Aus dem - nicht empfehlenswerten - Passwort RADIUS etwa wird so „r39q0m9cewbX7VMV“ (www.funk.com/radius/enterprise/pass_amp.asp).

Einfacher Paketaufbau

Das Radius-Protokoll ist sehr einfach gehalten und kennt nur einige wenige Typen von Datenpaketen, die alle den im folgenden beschriebenen Aufbau haben: Den Typ des Pakets bezeichnet das erste, „Code“ genannte Byte. Die Liste aller bisher definierten Pakettypen ist erfreulich kurz:

Code  Pakettyp
   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

Ablauf einer Authentifizierung

Im Einzelnen bedeutet das für eine Authentifizierung: Der Benutzer meldet sich bei einem NAS mit seiner Kennung und seinem Passwort an. Der NAS agiert als Radius-Client und baut ein Access-Request-Paket zusammen, gekennzeichnet durch die „1“ im ersten Byte. Das zweite Byte erhält einen eindeutigen Identifier, den der RAS-Server zwecks Zuordnung von Anfrage und Ergebnis in sein Antwortpaket übernimmt. Die Längenangabe (2 Byte) im nächsten Feld gibt die Gesamtlänge des kompletten Pakets einschließlich aller Attribute an. Das nächste Feld, den aus 16 Bytes bestehenden Authenticator, setzt der Radius-Client auf einen zufällig gewählten Wert. Der Server verwendet unter anderem dieses Feld, um seine Antwort zu authentisieren (siehe unten). Anschließend können noch beliebige Attribute folgen.

Der Radius-Server beantwortet die Authentifizierungsanfrage entweder positiv mit einem Access-Accept (Code 2) oder ablehnend mit einem Access-Reject (Code 3). Als ID verwendet er den Wert aus dem Access-Request-Paket, auf das er antwortet.

Damit der Client sicher weiß, dass die Antwort tatsächlich vom zuständigen Radius-Server kommt und die Integrität des Paktes unverletzt ist, berechnet der Server den MD5-Hash des kompletten Pakets (mit dem Request-Authenticator des Clients im Authenticator-Feld) zusammen mit dem „Shared Secret“. Die so ermittelte kryptographische Prüfsumme setzt er als Response-Authenticator in das Authenticator-Feld der Antwort ein. Bei einer Manipulation des Pakets wird der Hash-Wert nicht mehr stimmen und der Client die Antwort verwerfen. Den korrekten Hash-Wert kann nur jemand berechnen, der auch das Shared Secret kennt.

Man beachte, dass Radius lediglich Maßnahmen zum Schutz der Integrität des Pakets und zur Sicherstellung der Authentizität kennt. Vertraulichkeit ist kein Thema, alle Informationen (vom Passwort abgesehen) fließen im Klartext.

Radius-Pakete haben eine recht simple, immer gleiche Grundstruktur. Trotzdem wird dieses Verfahren allen Anforderungen im Alltagsbetrieb gerecht. Denn die optional verwendbaren Attribute ermöglichen es, nahezu jede gewünschte Information zwischen Client und Server auszutauschen.

Selbst so grundlegende Dinge wie die Art der Übermittlung von Benutzername und Passwort bei der Anmeldung sind keine festen Bestandteile eines Access Request, sondern gegebenenfalls durch Attribute geregelt. Hierdurch erhält das Radius-Protokoll eine hohe Flexibilität, die sicherlich mit dazu beigetragen hat, dass es sich so breit durchsetzen konnte.

Attribute werden als Attribute-Value-Pair (AVP) im in Abbildung 1 gezeigtem Format verwendet. Um welches Attribut es sich handelt, ist durch die Nummer (A-NR) festgelegt. „Length“ (A-LEN) gibt die Länge des gesamten Attribut-Eintrags (einschließlich Nummer und A-LEN) an.

Hier eine kleine Auswahl der circa 90 zurzeit definierten Radius-Attribute, Näheres zu den Attributen ist den RFCs 2865 bis 2869 zu entnehmen:

  1   User-Name               Benutzername für Anmeldungen    
  2     User-Password           verschlüsseltes Passwort für PAP        
  3     CHAP-Password           Antwort auf Challenge bei CHAP  
 19     Callback-Number         hinterlegte Rufnummer für Rückruf       
 26     Vendor-Specific         herstellerspezifische Erweiterung       
 40     Acct-Status-Type        Accounting Start/Stop/Update    
 60     CHAP-Challenge          hier oder im Feld Authenticator 
 79     EAP-Message             bei Nutzung des Extensible Authentication Protocol

Für jedes Attribut ist das zu verwendende Datenformat und gegebenenfalls die genaue Bedeutung bestimmter Zahlenwerte festgelegt, ebenso, wie und in welcher Radius-Paket-Art es verwendet werden darf und in welcher nicht.

Für besondere Flexibilität sorgt das Attribut Nummer 26 „Vendor Specific“. Hier können NAS-Hersteller eigene Attribute für ihre speziellen Zwecke ergänzen und so Radius erweitern.

Eine aus 4 Bytes bestehende Vendor-ID leitet das herstellerspezifische Attribut ein. Nach einem führenden Null-Byte findet sich hier die aus 3 Bytes bestehende, weltweit eindeutig durch die IANA auf Antrag vergebene Firmennummer (SMI Network Management Private Enterprise Code, siehe www.iana.org/assignments/enterprise-numbers).

Es folgen die eigentlichen Nutzdaten als Binärfolge. Wie diese zu interpretieren und zu behandeln ist, kann jeder Hersteller selbst festlegen. Um die Interoperabilität verschiedener Radius-Implementierungen zu gewährleisten, darf ein Server unbekannte Attribute ignorieren. Es ist dann Sache des Clients, darauf geeignet zu reagieren.

Mit Hilfe der Attribute können sich Radius-Client und Server darüber verständigen, wie die Authentifizierung erfolgen soll, ob besondere Dienstmerkmale anzuwenden sind, ob bei Einwahl über Modem oder ISDN ein Rückruf auszulösen ist und so fort.

Den vollständigen Text über Einsatzszenarien und elaboriertere Features von Radius finden Sie in der aktuellen Printausgabe. (js)