Ein Überblick über aktuelle Arbeiten

Ein Überblick über aktuelle Arbeiten
Seminarausarbeitung
Universität Bonn
Institut für Informatik
Abteilung IV –
Prof. Dr. Peter Martinti
Vorgelegt von
Gerwin Brill
20.11.2001
Inhaltsverzeichnis:
Seite
1.
2.
2.1
2.2
2.3
3.
3.1
3.2
3.2.1
3.3
4.
4.1
4.1.1
4.1.2
4.1.3
4.2
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
4.2.6
4.2.6.1
4.2.6.2
4.2.6.3
5.
6.
Einleitung und Motivation
Allgemeine Beschreibung von AAA-Systemen
Begriffsdefinition
Allgemeine AAA-Systemarchitektur
Abwärtskompatibilität mit bestehenden Protokollen
Anforderungen an AAA-Protokolle
Authentifizierung
Autorisierung
Autorisierungssequencen
Accounting
Existierende AAA-Protokolle
RADIUS
Arbeitsablauf von RADIUS
RADIUS-Accounting
Arbeitsablauf von RADIUS-Accounting
DIAMETER
Unzulänglichkeiten bei RADIUS
ROAMOPS Modell
DIAMETER Architektur
DIAMETER Basis-Protokoll
DIAMETER Roaming Support
DIAMETER Erweiterungen
Strong Security Erweiterung
NASREQ Erweiterung
Accounting Erweiterung
Zusammenfassung
Quellenangabe
3
3
3
4
6
6
7
7
8
10
11
11
12
14
15
16
16
17
18
18
20
21
21
21
22
22
23
1. Einleitung und Motivation
Wir leben in einer Zeit, in der Informationen und die zugrundeliegenden
Technologien und Infrastrukturen zu einem enorm wichtigen
wirtschaftlichen Faktor geworden sind. Die globale Vernetzung und die
Qualität der digitalen Autobahn wächst in einem immer schnelleren Maße.
Die Internettechnologie kennt keine geografischen Grenzen und
ermöglicht uns in Sekundenschnelle um die ganze Welt zu reisen.
Personen oder Institutionen, die innerhalb des globalen Dorfes
kommerzielle Dienste anbieten wollen, stehen vor dem Problem, dass das
Internet ein quasi rechtsfreier Raum ist, da es bislang kaum nationale
oder internationale Gesetze gibt, die das Zusammenleben in der digitalen
Welt regeln.
Um diesen Umständen Rechnung zu tragen, benötigt man Mechanismen,
die es einem ermöglichen seine Dienste vor Missbrauch zu schützen.
Konkret bedeutet dies, dass man z.B. nicht beliebigen Personen Zugriff
gewähren möchte (Authentication), sondern nur solchen, denen man auch
im späteren die Nutzung der Dienste in Rechnung stellen kann
(Accounting). Außerdem ist es extrem wichtig darüber zu wachen, dass
die Benutzer auch nur die Teile des Systems zu sehen bekommen, die für
sie bestimmt sind (Authorisation).
In dieser Seminararbeit geht es um den Stand der Entwicklung auf dem
Gebiet der AAA-Systeme.
Die Abkürzung AAA bedeutet Authentifizierung, Autorisierung und
Accounting und beschreibt genau die oben definierten Problemfälle.
2. Allgemeine Beschreibung von AAA-Systemen
2.1
Begriffsdefinition
Die Abkürzung AAA steht für Authentifizierung, Autorisierung und
Accounting.
Die Begriffe werden im Folgenden synonym mit diesen Definitionen
verwendet:
Authentifizierung ist der Vorgang der Überprüfung einer
angegebenen Identität. Dabei kann man zwischen der
Authentifizierung des Senders bzw. des Empfängers einer Nachricht
(message authentication vs. authentication of the channel end
point) unterscheiden. Beispielsweise muss sich ein GSM-Handy
immer gegenüber dem Netz identifizieren. Umgekehrt geschieht dies
nicht.
Autorisierung ist der Vorgang der Überprüfung, ob bestimmte
(Zugriffs-) Rechte einem (authentifizierten) Benutzer zugesprochen
werden können oder nicht. Dabei kann es sich z.B. um
Zugriffsrechte für Netzlaufwerke handeln.
Accounting beschreibt den Vorgang der Sammlung von Daten bzgl.
Resourcenverbrauch für Abrechnungszwecke, Kapazitätsplanungen,
Statistiken etc.
Im Augenblick bestehen Realisierungen dieser drei Dienste aus
verschiedenen speziellen Protokollen, die die gewünschten Funktionen für
mehr oder weniger spezielle Anwendungen implementieren.
Aufgrund
des
wachsenden
Bedarfs
nach
derartigen
Sicherheitsmechanismen entstand innerhalb der IETF eine Arbeitsgruppe,
die AAAarch Research Group, die es sich zum Ziel gemacht hat, eine AAASystem-Architektur zu schaffen, die allgemein und flexibel genug ist, dass
sie für beliebige Anwendungen verwendet werden kann.
2.2
Allgemeine AAA System-Architektur
Eine typische AAA Infrastruktur besteht aus AAA Servern, die
untereinander in Verbindung stehen und ein spezielles AAA Protokoll zur
Kommunikation benutzen, sowie AAA Clients.
Folgendes Diagramm zeigt eine Übersicht:
Request
Client
Response
Application
Specific
Module
(ASM)
AAAServer
Policy and
event
repository
AAAServer
Unterschiedl.
Protokolle
Abbildung 1 – Übersicht der Elemente in einer allgemeinen AAA SystemArchitektur
Abbildung 1 zeigt die Systemarchitektur
applikationsunabhängigen AAA-Systems.
eines
allgemeinen,
Bei diesem Ansatz wird die AAA Funktionalität in zwei Bereiche unterteilt:
einen allgemeinen Teil, der typisch für alle Anwendungen ist, und einen
applikationsspezifischen Teil. Die unterschiedlichen Farben der
Interaktionspfeile markieren, dass die Clients zur Kommunikation mit dem
AAA-Server, sowie die AAA-Server untereinander, ein spezielles Protokoll
verwenden. Auf die internen Protokolle mit den Farben Grün und Rot wird
hier nicht weiter eingegangen.
Der generische AAA-Server hat die Aufgabe Clientanfragen zu analysieren
und Authentifizierungs-/Autorisierungsentscheidungen zu treffen. Zu
diesem Zweck besitzt er Regeln (logische und/oder algebraische Formeln)
und mehrere Hilfskomponenten, die die notwendigen Informationen liefern
können.
Das ASM (Application Specific Module) stellt die Schnittstelle zu den
applikationsspezifischen Informationen dar. Das ASM verwaltet die
Ressourcen und konfiguriert die Dienste, die für einen autorisierten
Benutzer freigeschaltet werden können.
Zudem kann das ASM auch an Autorisierungsvorgängen beteiligt sein, da
es über applikationsspezifische Informationen verfügt.
Das Event Log stellt das Gedächtnis des AAA-Systems dar. In dieser
Datenbank wird über alle aufgetretenen Ereignisse chronologisch
buchgeführt. Im einfachsten Fall handelt es sich dabei lediglich um einen
einfachen Logging-Mechanismus. Diese Informationen können aber auch
Autorisierungsentscheidungen als Grundlage dienen. Es gibt beispielweise
Anwendungsfälle, in denen eine Autorisierung nur dann gewährt werden
kann, wenn ein spezielles anderes Ereignis in der Vergangenheit bereits
aufgezeichnet wurde.
Das Policy Repository zuletzt ist eine Datenbank, die die verfügbaren
Dienste verwaltet und Auskünfte darüber erteilt, welche Autorisationsfälle
entschieden werden können. Zudem hat es Kenntnis darüber, welche
Regeln einer konkreten Autorisierungsentscheidung zugrunde liegen
müssen.
Ein wichtiger Punkt ist zudem noch, dass AAA-Server Proxy-Fähigkeit
besitzen müssen. Ein AAA-Server, der nicht über die gewünschten
Informationen verfügt, muss in der Lage sein, die Anfrage an einen
anderen AAA-Server weiterzuleiten. Zu diesem Zweck sollte das Protokoll,
dass der Kommunikation zwischen den AAA-Server zugrunde liegt, ein
Peer-2-Peer-Protokoll sein, in dem Sinne, dass jeder Node gleichzeitig als
Server und als Client im Netz auftreten kann.
In dieser Architektur wird eine Autorisierungsanfrage wie folgt bearbeitet:
1. Ein Benutzer stellt eine wohlformatierte Autorisierungsanfrage an
den Server. Wohlformatiert bedeutet in diesem Sinne, dass der AAA
Server keinerlei applikationsspezifische Informationen benötigt, um
eine Entscheidung auf Grundlage der Anfrage zu treffen.
2. Der AAA-Server überprüft die Anfrage, stellt fest, welche Art der
Autorisation benötigt wird, erhält eine Regel aus dem Policy
Repository und führt eine der folgenden Aktionen aus:
i)
ii)
iii)
Weiterleitung der Anfrage an das Application Specific
Module (ASM) zum Zweck der Evaluierung.
Autorisierungsentscheidung auf Grundlage der Daten aus
dem Policy Repository und dem Event Log.
Weiterleitung der Anfrage an einen anderen AAA-Server
In den Fällen 2.i und 2.ii sendet der AAA-Server anschließend die Antwort
an den initiierenden Client oder AAA-Server.
Im Falle 2.iii muss der AAA-Server auf die Antwort des angefragten
Servers warten.
2.3
Abwärtskompatibilität mit bestehenden Protokollen
Da heutzutage bereits sehr viele AAA-Implementierungen existieren und
man durch die Entwicklung einer neuen standardisierten Architektur die
Investitionen in die bestehenden Systeme nicht gefährden möchte, muss
ein Weg gefunden werden, die herkömmlichen Systeme in die neuen
Strukturen zu integrieren.
Eine möglicher Lösungsansatz ist die Verwendung von AAA-Gateways.
‚herkömmlicher’
Client
AAAGateway
AAAServer
(s. Abbildung 1)
Abbildung 2 – Kopplung herkömmlicher Protokolle durch AAA-Gateways
Das AAA-Gateway übernimmt die Funktion einer ‚Umladestation’ in dem
es die PDUs (Protocol Data Units) des herkömmlichen Protokolls in die
PDUs des neuen AAA-Protokolls verpackt.
Der AAA-Server, der diese verpackten Nachrichten erhält, kann ohne
Kenntnis über die Protokolldetails mit Hilfe des ASM eine adäquate
Entscheidung treffen.
3. Anforderungen an AAA-Protokolle
Es gibt einige grundsätzliche Anforderungen an AAA-Protokolle. Thema
dieses Abschnitts ist es, diese Anforderungen zu konkretisieren.
3.1
Authentifizierung
Authentifizierung bedeutet einerseits (irgendwie) sicher zu stellen, dass
man tatsächlich mit der Instanz kommuniziert, die sie vorgibt zu sein.
Dies bezeichnet man auch als ‚authentication of the channel end point’.
Andererseits ist es sehr oft gebräuchlich, dass sich der Initiator der
Nachricht zusätzlich gegenüber dem Empfänger ausweist. Dies ist
insbesondere dann wichtig, wenn ein Dienst in Anspruch genommen
werden soll. Der Dienst darf nur dann freigeschaltet werden, wenn sicher
festgestellt worden ist, dass die Instanz, mit der Kommuniziert wird, auch
die ist, die sie vorgibt zu sein. Dies bezeichnet man auch mit
‚authentication of the message originator’.
Authentifizierung kann auf verschiedenste Arten und Weisen geschehen.
Die wohl gebräuchlichste und zugleich die unsicherste Methode ist die
Kombination aus Benutzername und Passwort. Unsicher deshalb, weil
Passwörter, besonders wenn sie von den Anwendern selber gewählt
werden können, meistens kurz und deshalb leicht zu brechen sind.
Sicherere Methoden sind z.B. die Verwendung von Public-Key-Kryptografie
oder Challenge-Response-Schemata.
Authentifizierung ist ein wichtiger Bestandteil bei sicherheitskritischen
Diensten, da es viele verschiedene Sicherheitsanforderungen abdeckt.
Dazu gehört Schutz vor Man-In-The-Middle und Replay Attacken
(Mitschneiden des Datenverkehrs und Wiederverwendung aufgezeichneter
Nachrichten) etc.
3.2
Autorisierung
Ein Autorisierungsvorgang ist gleichbedeutend mit der Frage, ob ein
Benutzer ausreichende Rechte besitzt eine angeforderte Resource
zugeteilt zu bekommen oder nicht.
Normalerweise steht eine Autorisierungsprozedur in der Folge nach einer
bereits erfolgreich durchgeführten Benutzerauthentifizierung.
An einer Autorisierungsprozedur können für gewöhnlich bis zu vier
Instanzen beteiligt sein:
1. Der anfragende Benutzer, der zum Zugriff auf einen Dienst
autorisiert werden muss.
2. Die Heim-Organisation (HO; home organization) des Benutzers.
Dies ist die Instanz, mit der der Benutzer einen Vertrag
abgeschlossen hat und die in der Lage ist zu prüfen, ob der spezielle
Benutzer das Recht hat den angeforderten Dienst in Anspruch zu
nehmen. Die HO besitzt besitzt also die benötigten Informationen,
z.B. über den Kredit des Benutzers, um die Frage der Autorisierung
adäquat beantworten zu können.
3. Der AAA-Server des Service-Providers, der den Dienst abhängig
von dem Vertrag des Benutzers mit seiner HO freischalten kann
oder nicht.
4. Das Service-Equipment des Service Providers, das den
gewünschten Dienst erbringt. Dies kann z.B. der Network-AccessServer (NAS) eines Internet-Service-Providers sein, der seinen
Kunden einen Modem-Einwahlpool zur Verfügung stellt.
Die wesentlichen Anforderungen an Autorisierungsprozeduren in
Systemen lassen sich in den folgenden Punkten zusammenfassen:
3.2.1
AAA-
Ein AAA-Protokoll sollte separate und muss kombinierte
Authentifizierungs- und Autorisierungs-Nachrichten unterstützen.
Ein AAA-Protokoll muss proxyfähig sein, d.h. es muss eine
Benutzeranfrage an einen anderen AAA-Server zur Bearbeitung
weiterleiten können.
Wenn Vermittlungsknoten (Broker) an einer Kommunikation
zwischen den Elementen eines AAA-Systems beteiligt sind, ist eine
Absicherung der Kommunikation auf Ende-zu-Ende-Basis nötig
Broker müssen in der Lage sein auf Anfrage die Adresse des
Kommunikationspartners mitzuteilen, an den die AAA-Nachrichten
weitergeleitet werden, damit die beteiligten Nodes auch direkt
miteinander kommunizieren können.
Autorisierungssequenzen
Es existieren drei verschiedene Autorisierungssequenzen: agent, push
und pull.
1. Agent-Sequence
In der Agent-Sequence fungiert der AAA-Server als Agent zwischen
dem Benutzer und dem Service-Equipment, das den Dienst zur
Verfügung stellt.
1
User
4
Service-Provider
AAA-Server
2
3
Service
equipment
Abbildung 3 – Agent-Seqence
1. Der Benutzer schickt seine Anfrage an den AAA-Server.
2. Der AAA-Server wendet eine dem Benutzer entsprechende Regel
an und sendet nach erfolgter Autorisierung die Anfrage weiter an
das Service-Equipment.
3. Das Service-Equipment startet den Dienst und meldet
anschließend dem AAA-Server, dass der Dienst nun für den
Benutzer bereitsteht.
4. Der AAA-Server meldet dem Benutzer, dass der gewünschte
Dienst nun zur Verfügung steht.
2. Pull-Sequence
In der Pull-Sequence stellt der Benutzer seine Anfrage nach einem
gewünschten Dienst direkt an das Service-Equipment (1).
Das Service-Equipment seinerseits sendet die Anfrage zur
Entscheidung an den AAA-Server (2). Der AAA-Server entscheidet auf
Grundlage seiner Informationen und teilt dem Service-Equipment
anschließend mit, den Dienst zu starten oder auch nicht (3). Der
Service-Equipment startet den Dienst, wenn die Autorisierungsprozedur
erfolgreich war und meldet dem Benutzer, dass der Dienst nun zur
Verfügung steht (4).
Abbildung 4 zeigt ein Schema der Pull-Sequence.
Service-Provider
AAA-Server
User
1
4
3
2
Service
equipment
Abbildung 4 – Pull-Sequence
3. Push-Sequence
Die folgende Abbildung schematisiert die Push-Sequence.
1
User
Service-Provider
AAA-Server
2
3
4
Service
equipment
Abbildung 5 – Push-Sequence
In der Push-Sequence fragt der Benutzer den AAA-Server an, ob er
autorisiert ist den gewünschten Dienst zu benutzen (1). Besteht er
diese Prüfung, bekommt er vom AAA-Server ein Ticket ausgestellt (2).
Mit diesem Ticket ausgestattet wendet er sich nun an das ServiceEquipment und bittet es den Dienst zu starten (3).
Wenn der Dienst bereitsteht, meldet das Service-Equipment dies an
den Benutzer (4).
3.3
Accounting
Beim Accounting sammelt man Daten über den Verbrauch von Ressourcen
zu Analyse-, Planungs- und Abrechnungszwecken. In allen
Anwendungsfällen, in denen Accounting eingesetzt wird, gibt es
Sicherheitsanforderungen, die erfüllt sein müssen, damit dieser Dienst
zuverlässig funktioniert.
Besonders wichtig ist die Unterscheidung, ob Accounting innerhalb einer
administrativen Zone (Domäne) stattfindet (intra domain accounting),
oder ob die Domänengrenzen verlassen werden (inter domain
accounting). Da sich beim Inter-Domain-Accounting ein Teil der
Datensammlung und -übermittlung der eigenen administrativen Kontrolle
entzieht, ist diese Art wesentlich anfälliger gegenüber Verletzungen der
Sicherheit.
Da die AAAarch Gruppe keinerlei Aussagen über das zu verwendende
Transportprotokoll macht, muss insbesondere auch über die
Wahrscheinlichkeit und Konsequenz von Paketverlusten nachgedacht
werden.
Trendanalyse und Kapazitätsplanungen
Bei Trendanalyse und Kapazitätsplanung ist es kein Problem eine
moderate Paketverlustrate in Kauf zu nehmen, da es ‚lediglich’ darum
geht die zukünftige Netzwerkauslastung abzuschätzen. In diesem
Anwendungsfall muss Accounting also in der Lage sein mit geringen
(intra-domain-accounting) bzw. höheren (inter-domain-accounting)
Verlustraten robust umzugehen.
Abrechnung (Billing)
Wenn Accounting zum Zweck der Abrechnung von verbrauchten
Leistungen eingesetzt werden soll, muss man prinzipiell zwei Fälle
unterscheiden. Im ersten Fall findet eine Abrechnung unabhängig von den
tatsächlich verbrauchten Leistungen statt. Dieser Fall ist also verglichen
harmlos, weil selbst bei Totalverlust aller übermittelten Verbrauchsdaten
kein finanzieller Schaden entsteht.
In dem verbrauchsabhängigen Fall hingegen können schon geringe
Datenverluste bzw. –verzögerungen einen großen finanziellen Schaden für
den Dienstanbieter bedeuten. In diesem Anwendungsfall ist somit ein
archivarischer Ansatz erforderlich, der es erlaubt Paketverluste durch
Wiederholungen zu kompensieren.
Kostenumlage (cost allocation)
Cost-Allocation und Bill-Back-Methoden bieten die Möglichkeit auf ein
Firmennetzwerk zuzugreifen und die dabei entstehenden Kosten direkt,
ohne Umweg über die eigene Brieftasche, der Firma in Rechnung zu
stellen. Ein typischer Anwendungsfall sind z.B. Außendienstmitarbeiter, die
mit ihrem Laptop auf das Intranet der Firma zugreifen müssen.
Wenn Accounting zu diesem Zweck eingesetzt werden soll, sind genau
dieselben
Sicherheitsund
Verfügbarkeitsanforderungen
zu
berücksichtigen wie im Billing-Fall.
4. Existierende AAA-Protokolle
In diesem Abschnitt gibt einen Überblick über zwei existierende
vollwertige AAA Protokolle geben: RADIUS und DIAMETER
4.1 RADIUS (Remote Authentication Dial In User Service)
RADIUS ist ein weit verbreitetes Protokoll zum Zweck der Übertragung
von Authentifizierungs- , Autorisierungs- und Konfigurationsinformationen
zwischen einen Network Access Server (NAS) und einem AutorisierungsServer. RADIUS Accounting ist kein Bestandteil der eigentlichen RADIUSSpezifikation, wurde jedoch durch eine Erweiterung fester Bestandteil der
RADIUS-Funktionalität, so dass RADIUS zu einem vollständigen AAAProtokoll gewachsen ist.
Folgende Eigenschaften zeichnen das RADIUS-Protokoll aus:
Client/Server-Modell:
Ein Network Access Server (NAS) fungiert als RADIUS-Client. Der
Client
ist
dafür
verantwortlich
die
benötigten
Benutzerinformationen an den RADIUS-Server zu übermitteln und
auf der Grundlage der Antwort des Servers weiter mit der Anfrage
zu verfahren. Der RADIUS-Server besitzt also die nötige Logik
Benutzeranfragen zu bearbeiten, die Benutzer zu authentifizieren
und autorisieren und anschließend alle notwendigen
Konfigurationsinformationen an den Client zu senden, damit dieser
den Dienst für den Nutzer starten kann.
Netzwerksicherheit:
Alle Transaktionen zwischen dem Client und einem RADIUS-Server
werden durch symmetrische Verschlüsselung (shared secret)
authentifiziert. Der gemeinsame geheime Schlüssel wird dabei
niemals im Klartext über das Netzwerk übertragen. Zusätzlich
werden alle Benutzerpasswörter, die zwischen den Clients und
einem Server übertragen werden, verschlüsselt. Damit wird
versucht zu verhindern, dass ein Angreifer aus dem Mitlesen des
Netzwerkverkehrs Rückschlüsse auf die verwendeten Passwörter
ziehen kann.
Flexibler Authentifizierungsmechanismus:
RADIUS arbeitet mit einer Vielzahl von möglichen
Benutzerauthentifizierungsmechnismen zusammen. Dazu gehören
PPP, PAP oder CHAP, UNIX login etc.
Erweiterbares Protokoll:
Alle Nachrichten im RADIUS-System umfassen Attribut-Länge-Wert
3-Tupel mit variabler Länge. Neue Attribute-Value-Paare (AVP)
können leicht hinzugefügt werden, ohne bestehende
Implementierungen dieses Protokolls zu stören.
4.1.1 Arbeitsablauf von RADIUS
Wenn ein Client dafür konfiguriert ist, das RADIUS-Protokoll zu benutzen,
fordert er seinen Nutzer dazu auf, sich gegenüber dem System zu
identifizieren und authentifizieren. Dies geschieht in der Regel dadurch,
dass der Benutzer durch ein Login-Prompt angewiesen wird einen
Benutzernamen und ein Passwort einzugeben. Durch die hohe Flexibilität
von RADIUS können auch Mechanismen wie PPP, PAP oder CHAP etc. zum
Einsatz kommen.
Anschließend erzeugt der Client einen sogenannten ‚Access-Request’, den
er an den RADIUS-Server sendet. Der ‚Access-Request’ enthält als
Attribute den Benutzernamen, das Passwort, die Client-ID und die Port-ID,
auf die der Benutzer zugreift. In dem Fall, dass ein Passwort mit dem
‚Access-Request’ übertragen werden soll, wird dieses mit einem auf dem
RSA Message Digest Algorithmus (MD5) basiertem Chiffre verschlüsselt.
Der
wird anschließend über das Netzwerk an den
übertragen. Falls innerhalb einer Timeout-Zeitspanne
nicht adäquat auf die Client-Anfrage geantwortet wird, so findet eine
Wiederholung der Anfrage vom Client an den Server statt, solange bis der
Client den Verbindungsversuch abbricht.
Die Clients haben ebenfalls die Möglichkeit den ‚Access-Request’ an
alternative Server weiterzuleiten, falls der primäre Server down oder nicht
erreichbar ist.
‚Access-Request’
RADIUS-Server
Ein besonderer Fall ist derjenige, dass eine Verbindung von einem Client
zu dem gewünschten RADIUS-Ziel-Server über einen oder mehrere
RADIUS-Forwarding-Server ‚geschaltet’ ist. In der RADIUS-Architektur
kann ein Server sowohl die Funktionalität eines Forwarding-Server, als
auch die eines Remote-Servers übernehmen. Abbildung 6 stellt diese
Situation grafisch dar.
RADIUSClient
1
RADIUS-Client 1
kommuniziert mit RADIUSServer 1
RADIUS-
RADIUS-
Server 1
Server 2
RADIUSClient
2
RADIUS-Client 2
kommuniziert mit RADIUSServer 2
Abbildung 6 – RADIUS-Server als Forwarding- und Remoteserver
Die Farbbalken sollen in diesem Diagramm symbolisieren, dass jeweils
zwei an einer Kommunikation beteiligte Nodes einen gemeinsamen
geheimen Schlüssel besitzten. Da in einer RADIUS-Transaktion niemals
ein Benutzerpasswort im Klartext über das Netz verschickt werden darf,
sorgt dieser Mechanismus dafür, dass eine Verbindung über ForwardingServer stehts gesichert ablaufen kann.
Wenn ein Server eine ‚Access-Request’-Nachricht erhält und er selber
nicht der Remote-Server ist, so finden die folgenden Schritte statt:
i)
ii)
iii)
Der Forwarding-Server dechiffriert das Benutzerpasswort
mit dem Schlüssel, den er sich mit dem sendenden Client
oder Forwarding-Server teilt.
Anschließend wird die Client-ID auf den neuesten Stand
gebracht.
Zum Schluss Verschlüsselt der Forwarding-Server das
Benutzerpasswort mittels desjenigen Schlüssels, den er
sich mit dem Remote-Server oder dem nächsten
Forwarding-Server teilt und schickt die Nachricht weiter.
Hat der gewünschte Remote-Server letztendlich den initiierenden ‚Accesserhalten, validiert er den Client, von dem er die Nachricht
erhalten hat. Hat der Server die Nachricht nicht direkt, sondern über einen
Forwarding-Server erhalten, so ist aus Sicht des Remote-Servers eben
diese letzte Station der Client.
Validierung heißt in diesem Fall, dass der Remote-Server anhand der
Client-ID überprüft, ob er sich mit diesem Client ein Geheimnis teilt,
sprich ob ein gemeinsamer Schlüssel zur Dechiffrierung der Nachricht
vorhanden ist. Erhält ein Server eine Nachricht von einem Client, der
keine Bekannte ID hat, so muss diese Nachricht ohne eine Antwort
vernichtet bzw. ignoriert werden.
Request’
Wenn festgestellt wurde, dass der Client dem Server bekannt ist, kann der
Remote-Server den ‚Access-Request’ bearbeiten. Zu diesem Zweck fragt
der Server eine interne Datenbank ab, ob die Informationen zu dem
anfragenden Benutzer lokal verfügbar sind. Wird ein solcher Datensatz
gefunden, erhält der Server eine Liste mit Bedingungen aus dem Policy
Repository, die erfüllt sein müssen, um dem Benutzer Zutritt zu
gewähren.
Dieses beinhaltet immer die Überprüfung des Passworts.
Jetzt besteht noch die Möglichkeit, dass der Server einen weiteren
Authentifikationsschritt durch ein Challenges/Response-Schema verlangt.
Dies geschieht dadurch, dass der Server mit einem ‚Access-Challenge’ auf
den ‚Access-Request’ antwortet. Ein Challenge/Response-Schema ist eine
weitaus sicherere Methode, da der Server eine dynamische
Herausforderung (Challenge) erzeugt, die (eigentlich) nur der Benutzer
selber durch z.B. ein Chipkarte oder einen nur ihm zugänglichen
Algorithmus bewältigen bzw. beantworten kann.
Nach Eingabe der Benutzerantwort erzeugt der Client eine neue ‚AccessRequest’ Nachricht, in dem er die originale ‚Access-Request’ Nachricht mit
einer neuen Request-ID ausstattet und das User-Passwort-Attribut durch
die (verschlüsselte) Challenge-Response ersetzt. Diese Nachricht wird nun
an den Server zurückgeschickt.
Der Server kann auf diese neue ‚Access-Request’ Nachricht mit einer
‚Access-Accept’,
‚Access-Reject’ oder ‚Access-Challenge’ Nachricht
antworten.
Der RADIUS-Server hat nun wiederum die Möglichkeit andere Server zu
kontaktieren, um eine Entscheidung bzgl. des ‚Access-Request’ treffen zu
können.
Wenn eine der Bedingungen nicht erfüllt sein sollte, sendet der Server ein
‚Access-Reject’, um dem Benutzer mitzuteilen, dass er keinen Zugriff auf
das System bekommt.
Wenn alle Bedingungen an den Benutzer erfüllt sind, wird die Liste der
Konfigurationsvariablen in eine ‚Access-Accept’ Nachricht verpackt. Diese
Variablen definieren den Service-Typ (z.B. SLIP, PPP, Login User) und alle
nötigen Informationen, um den Dienst zu starten. Zu diesen Information
gehören bei z.B. einer PPP- oder SLIP-Verbindung die zugewiesene IPAdresse, Subnetzmaske, MTU etc.
4.1.2. RADIUS-Accounting
Accounting ist kein Bestandteil des ursprünglichen RADIUS-Protokolls.
RADIUS-Accounting wurde später in einer Erweiterung dem RADIUSProtokoll hinzugefügt.
Diese Protokollerweiterung beschreibt die Übertragung von AccountingInformationen von einem Network Access Server zu einem RADIUSAccount-Server.
Identisch zu den Merkmalen des ursprünglichen RADIUS-Protokolls
fungiert auch bei RADIUS-Accounting der NAS (Network Access Server)
als Client. Er hat die Aufgabe einem speziellen Accounting-Server die
gesammelten Informationen zum Ressourcenverbrauch der Nutzer
zukommen zu lassen. Der RADIUS-Accounting-Server hat im Gegenzug
die Aufgabe diese Informationen zu empfangen und zu speichern und dem
Client die eingegangenen Accounting-Nachrichten zu quittieren.
Auch in dieser Architektur kann ein Accounting-Server als Proxy auftreten
und Accounting-Nachrichten an andere Accounting-Server weiterleiten.
Ebenfalls identisch ist, das jegliche Transaktionen zwischen einem
RADIUS-Client und einem RADIUS-Accounting-Server durch einen
symmetrischen Schlüssel authentifiziert und gesichert werden.
4.1.3 Arbeitsablauf von RADIUS-Accounting
Wenn ein Client für die Benutzung von RADIUS-Accounting konfiguriert
wurde, dann geschieht folgendes, wenn ein Benutzer einen Dienst in
Anspruch nehmen möchte und dieser Dienst dann auch gestartet wird:
Der NAS generiert beim Start des Dienstes eine Accounting-Start
Nachricht. Innerhalb dieser Nachricht übermittelt er, welcher Dienst
gestartet wurde und welcher Benutzer diesen Dienst in Anspruch nimmt.
Nachdem die Nachricht zum Accounting-Server übertragen wurde
generiert dieser als Antwort eine Quittung, die bescheinigt, dass die
Accounting-Nachricht angekommen ist.
Wenn der Nutzer den Dienst nicht länger in Anspruch nehmen möchte
oder der Dienst aus irgendeinem anderen Grunde gestoppt wurde, sendet
der NAS eine Accouting-Stop Nachricht an den Accounting-Server. Inhalt
dieser Nachricht ist der Typ des Dienstes der ‚verbraucht’ worden ist,
sowie optional statistische Informationen wie z.B. die vergangene Zeit,
Transfervolumen etc. Der Accounting-Server generiert wiederum ein
Quittung, die den korrekten Erhalt der Nachricht bestätigt.
Die
werden, wie die anderen
auch, über möglicherweise verlustbehaftete Kanäle
Accounting-Start bzw. –Stop-Nachrichten
RADIUS-Nachrichten
übertragen.
Da, wie schon in den Anforderungen an Accounting definiert, eine korrekte
Abrechnung verbrauchter Ressourcen ein extrem wichtiger und
finanzkritischer Bereich ist, sollten auf jeden Fall Retransmission-Timer
eingesetzt werden, damit die Accounting-Nachrichten solange gesendet
werden, bis der Accounting-Server den Erhalt quittiert und keine
Nachrichten verloren gehen.
Die Clients haben ebenfalls die Möglichkeit ihre Accounting-Pakete an
alternative Server zu schicken, falls der primäre Accounting-Server nicht
zur Verfügung stehen sollte. Ein alternativer Server kann entweder nach
einer gewissen Anzahl von Fehlversuchen an den primären Server
ausgewählt werden, oder es wurde von vorne herein eine Ringstruktur von
Backup-Servern vorgesehen, die alle nacheinander abgefragt werden
können.
4.2 DIAMETER
Das RADIUS-Protokoll, wie in Abschnitt 4.1 beschrieben, wurde dafür
konzipiert AAA-Dienste für PPP-Einwahl- und Terminal-Server-Zugänge zu
erbringen.
Seit dem Anfang der 90er Jahre (im letzten Jahrhundert), als RADIUS
entwickelt wurde, haben sich die Profile der Benutzer dieser Dienste
jedoch stark geändert. Heutzutage besteht der Wunsch, ähnlich wie bei
dem GSM-Mobilfunknetz, an jedem beliebigen Ort der Welt einen
Netzzugang zur Verfügung zu haben, ohne mit einem jeweils neuen,
lokalen Anbieter einen Zugangsvertrag abschließen zu müssen.
Die von der IETF initiierte Roaming Operations Working Group (ROAMOPS)
kam zu dem Schluss, dass RADIUS für diese neuen Anforderungen nicht
geeignet ist. Ergebnis dieser Untersuchung war die Entwicklung von
DIAMETER als der Nachfolger von RADIUS.
Das
wurde nicht von Grund auf neu entwickelt.
diente den Designern als Grundlage, dessen unzulängliche
Eigenschaften geändert und das um neue Bestandteile ergänzt worden ist.
Das Basiskonzept von DIAMETER stellt einen AAA-Dienst dar, der beliebig
erweiterbar ist, um somit auch mit zukünftigen Zugangstechnologien
problemlos zusammenzuarbeiten.
DIAMETER-Protokoll
RADIUS
4.2.1 Unzulänglichkeiten bei RADIUS
Dieser Abschnitt gibt einen kurzen Überblick über bekannte Probleme bei
RADIUS.
Limitierung der Attribut-Datenwerte:
Alle protokoll- und appliktionsspezifischen Informationen werden
bei RADIUS in Attribut-Länge-Wert Tripel verpackt. Dabei kodiert
das Attributfeld die Art, das Längenfeld die Größe und das Wertfeld
die eigentliche Information. Durch die Beschränkung auf ein Byte
für das Längefeld können in RADIUS nur sehr umständlich, durch
Fragmentierungen, längere Wertfelder übertragen werden.
RADIUS verwendet UDP als Transportprotokoll:
Durch die Wahl von UDP als Transportprotokoll für RADIUS PDUs
ergeben sich einige schwierige Implikationen.
sieht keine Flußkontrollmechnismen vor, so dass ein RADIUSsich nicht vor Überlastungen durch die Clients schützen
kann.
UDP
kennt
zwar
keine
Retransmission-Prozeduren,
Paketwiederholungen sind aber dennoch notwendig. Für einen
RADIUS-Server ist es nur über sehr zeitaufwendige Tricks möglich,
wiederholte Pakete zu erkennen und Duplikate zu vernichten. Dies
kann wiederum zu Retransmissions führen.
Keine Quittungen der Nachrichten auf Ende-zu-Ende-Basis:
RADIUS sieht keine Quittungen für Nachrichten auf Ende-zu-EndeBasis vor (NAS <-> RADIUS-Server), so dass oftmals unnötige
Nachrichtenwiederholungen vorkommen, obwohl der Server mit
der Bearbeitung der Ursprungsnachricht noch gar nicht fertig ist.
Uneffiziente Nutzung von Proxy-Servern:
Da RADIUS keine Möglichkeit vorsieht, Serverausfälle zu erkennen,
können Proxy-Server im Fehlerfall nicht selbständig alternative
Server auswählen, sondern sind auf die Timeout- und RetransmitFunktion des NAS angewiesen.
UDP
Server
4.2.2 ROAMOPS Modell
Die ROAMOPS-Arbeitsgruppe innerhalb der IETF hat eine Reihe von
Spezifikationen vorgeschlagen, die definieren, wie einem PPP-Benutzer ein
Internetzugang zur Verfügung gestellt werden kann, ohne dass er oder sie
sich in den Modem-Pool seines oder ihres Heimat Service Providers
einwählen muss.
Dieses kann dann erreicht werden, wenn es den Providern ermöglicht
wird, ihre vertraglichen Benutzer wechselseitig zu authentifizieren.
Konkret bedeutet dies, dass ein Benutzer sich in das Netzwerk eines
lokalen Anbieters einwählen kann, wenn dieser ein Roaming-Abkommen
mit dem Vetragsanbieter des Benutzers abgeschlossen hat.
Da dieses System nur dann effektiv funktionieren kann, wenn jeder ISP
mit jedem anderen einen solchen Roaming-Vertrag eingeht, bei der
gleichzeitig hohen Anzahl von Internet Service Providern am Markt, wurde
schnell deutlich, dass auch dieses Modell starken Einschränkungen
unterliegt.
Zur Lösung dieses Problems hat die Arbeitsgruppe ein neues Element
innerhalb der DIAMETER-Architektur definiert, ein sogenannter ‚Broker’,
dessen alleinige Aufgabe darin besteht, die Roaming-Veträge der ISPs
untereinander zu verwalten.
Eine Gruppe von Internet Service Providern zusammen mit einem Broker
wird auch ‚Roaming Konsortium’ genannt.
4.2.3 DIAMETER Architektur
Die DIAMETER-Architektur besteht aus dem Basis-Protokoll und einem
Satz von Protokoll-Erweiterungen (z.B. starke Sicherheit, NASREQ
(Network Access Server Requirements), Mobile-IP und Accounting).
Funktionen, die allen unterstützten Diensten gemeinsam sind, sind in das
Basis-Protokoll
implementiert,
während
applikationsspezifische
Funktionalitäten durch den Erweiterungsmechanismus hinzugefügt werden
können.
Das Basis-Protokoll muss von allen DIAMETER-Applikationen unterstützt
werden und definiert das PDU-Format, einige Protokollkommandos und
grundlegende Sicherheitsmechanismen.
Im Gegensatz zu
arbeitet das DIAMETER-Protokoll über SCTP
, das eine gesicherte Übertragung
durch wohldefinierte Retransmission- und Timeout-Mechanismen
garantiert. Außerdem verfügt SCTP über ein Windowing-Schema, dass den
AAA-Servern ermöglicht den Fluss der eingehenden Pakete zu regulieren.
Durch die Fähigkeit Zustandsinformationen der Kommunikationspartner
abzufragen, kann im Fehlerfall schnell auf Backup-Server zurückgegriffen
werden.
RADIUS
(Stream Control Transmission Protokoll)
Eingeführt durch die ROAMOPS-Arbeitsgruppe, ist das neue Netzelement
des Brokers in die Architektur eingeflossen.
Der Broker dient als zwischengeschalteter Server, der NAS-Anfragen an
die Heimat-ISPs der Benutzer weiterleitet. Um einen sicheren BrokerDienst zu realisieren, ist eine Ende-zu-Ende-Absicherung der Verbindung
zwischen NAS und Home-Server notwendig, damit Broker nicht in der
Lage , sind die Inhalte dieser Nachrichten zu manipulieren.
4.2.4 DIAMETER Basis-Protokoll
Das Basis-Protokoll definiert das Nachrichtenformat von DIAMETER, einen
Satz von Protokollkommandos und legt fest, wie die Nachrichten gesichert
transportiert werden können.
Für die Entwicklung des Basis-Protokolls (d.h. nur grundlegende
Eigenschaften mit dem Ziel der Erweiterbarkeit) wurden u.a. die folgenden
Ziele formuliert:
Leichtgewichtig und einfach zu implementieren
Unterstützung einer großen Anzahl von AVPs
Effiziente Verschlüsselung von Attributen (wie bei RADIUS)
Unterstützung für Herstellereigene AVPs und Kommandos
Zuverlässigkeit durch das unterlagerte SCT-Protokoll (SCTP)
Schnelle Erkennung unerreichbarer Peers
Unterstützung für unangeforderte Nachrichten an ‚Clients’
Ein
Session-Objekt
pro
Authentifizierungs/Autorisierungsanforderung
Unterstützung für Redirect-Dienste, um Proxys zu umgehen
Der Grundgedanke des DIAMETER Basis-Protokolls war nicht die Schaffung
eines
allumfassenden
AAA-Protokolls,
das
sämtliche
Applikationscharakteristika heute und in Zukunft abdecken kann, sondern
lediglich die Bereitstellung eines sicheren Transportdienstes für die
Nachrichten der verschiedensten applikationsspezifischen Erweiterungen.
Aus diesem Grunde sollte es leichtgewichtig und einfach zu
implementieren sein.
In DIAMETER werden alle Informationen in Attribut-Wert-Paare (AVPs)
verpackt. Ein AVP besteht aus drei Teilen:
Identifikationsnummer, Längenfeld, Datenfeld.
Die eindeutige Identifikationsnummer wird dazu verwendet, die
verschiedenen Inhalte des Datenfeldes zu unterscheiden bzw. zu
klassifizieren. Die Menge der möglichen Identifikationsnummer muss
natürlich so groß sein, dass auch zukünftige Protokollerweiterungen ihre
eigenen AVPs definieren können.
Im Gegensatz zum Client/Server-Modell im RADIUS-Protokoll, liegt
eine Peer-2-Peer Kommunikationsstruktur zugrunde. Diese
Struktur, in der jeder Peer sowohl als Client als auch als Server fungieren
kann, erlaubt es auch unangeforderte Nachrichten an die NASes zu
versenden. Dies hat sehr viele Vorteile gegenüber dem klassischen
Client/Server-Modell. Nun ist es z.B. möglich Accounting-Daten zu
sammeln und erst auf Anforderung an einen Server zu übertragen, bzw.
hat ein Server nun die Möglichkeit eine Benutzersitzung von sich aus zu
beenden.
DIAMETER
Das DIAMETER-Protokoll ist ein sitzungsorientiertes Protokoll. Für jeden
authentifizierten Nutzer wird eine Sitzung zwischen dem Initiator der
Authentifizierungs-/Autorisierungsanfrage und dem Heimat-DIAMETERServer verwaltet, die über die komplette Nutzungszeit global eindeutig ist.
Alle nachfolgenden DIAMETER-Transaktionen (z.B. Accounting) müssen
den Sitzungsbezeichner jeweils mit übertragen.
Um eine DIAMETER-Sitzung zu beenden, wird entweder eine ‚Session
Termination’-Nachricht verschickt, oder der Sitzungs-Timer läuft ab und
die Sitzung wird durch ein Timeout-Ereignis abgebrochen.
Dieser Mechanismus wurde implementiert, um eine Sitzung in jedem Fall
adäquat beenden zu können.
Da heutige Mikroprozessoren dafür ausgelegt sind, vier Byte Worte zu
verarbeiten, fordert das DIAMETER-Protokoll eine Ausrichtung auf 32-bit
für alle Header und das Datenfeld.
4.2.5 DIAMETER Roaming Support
Das DIAMETER-Protokoll wurde von Anfang an so konzipiert, um für
Roaming-Situationen anwendbar zu sein.
Zu diesem Zweck wurde von der ROAMOPS-Arbeitsgruppe das
Netzelement des Brokers eingeführt. Ein Broker fungiert in einem
DIAMETER-System entweder als Proxy-Server oder als Redirect-Server
und hat die Aufgabe eine Verbindung zwischen dem lokalen ISP und dem
Heimat
ISP
herzustellen,
um
Authentifizierungsbzw.
Autorisierungsinformationen austauschen zu können.
Abbildung 7 zeigt den Einsatz eines Brokers als Proxy-Server in einer
Roaming-Situation.
Network
Access
Server
Local ISP
Primary
Proxy
Server
Home ISP
Primary
Home
Server
2 nd
Proxy
Server
2 nd
Home
Server
Abbildung 7 – Broker als Proxy-Server
Wird ein
als
eingesetzt, so übernimmt er in der
die Aufgabe eines einfachen Routers.
erlauben
direkt zu kommunizieren,
indem sie einen Routing-Informationsservice bereitstellen.
Broker
Redirekt-Server
DIAMETER-Architektur
Redirekt-Server
DIAMETER-Peers
Wenn ein Redirekt-Server eine Anfrage erhält, wird eine RedirektResponse-Nachricht an den Initiator der Anfrage zurückgesendet, mit den
nötigen Informationen, die gebraucht werden, damit der lokale
DIAMATER-Server direkt mit dem Server des Heimat ISPs in Kontakt
treten kann.
Abbildung 8 verdeutlich diese Situation.
Redirect
Server
Request
Response mit
Result Code=
Redirect
Local
DIAMETER
Server
Direkte
Kommunikation
Home
DIAMETER
Server
Abbildung 8 – Broker als Redirect-Server
4.2.6 DIAMETER Erweiterungen
Die DIAMETER-Architektur besteht aus dem DIAMETER Basis-Protokoll und
einem Satz von Erweiterungen, von denen einige in diesem Abschnitt kurz
eingeführt werden sollen.
4.2.6.1 Strong Security Erweiterung
Das DIAMATER Basis-Protokoll ermöglicht DIAMETER-Servern eine sichere
Kommunikation mittels hop-by-hop Authentifizierung. Hop-by-Hop
Authentifizierung bedeutet, dass der anfragende Server eine gesicherte
Kommunikation mit einem Proxy- oder Redirect-Server nutzt, und der
Proxy wiederum nutzt eine sichere Verbindung mit dem Home-Server
(siehe RADIUS).
Die Strong-Security-Erweiterung bietet starke Verschlüsselung für
ausgewählte AVPs. Dies wird für eine gesicherte Kommunikation auf Endezu-Ende-Basis benötigt, wenn die Verbindung über Proxy-Server
geschaltet ist.
4.2.6.2 NASREQ (Network Access Server Requirements) Erweiterung
Die NASREQ Erweiterung bietet Authentifizierung und Autorisierung für
Einwahl-PPP-Nutzer und Terminal-Server-Zugänge.
Diese Erweiterung benutzt dazu direkt die in RADIUS definierten AVPs, um
die benötigten Informationen zu übertragen. Diese Methode wurde
benutzt, um eine einfachere Migration von existierenden RADIUS-Servern
hin zu der DIAMETER zu ermöglichen, da so die bestehenden Nutzerprofile
weiterverwendet werden konnten.
Außerdem wird so der Rechenaufwand für Systeme minimiert, die in
einem Inter-Working-System als Bridge zwischen den bestehenden
RADIUS- und den neuen DIAMETER-Systemen fungieren.
4.2.6.3 Accounting Erweiterung
Die Accounting Erweiterung bietet eine Verbrauchsermittlung sowohl für
die Mobile-IP Erweiterung, die hier nicht weiter besprochen wird und die
NASREQ Erweiterung.
Wie das
überträgt DIAMETER die Accountinginnerhalb von Attribut-Wert-Paaren (AVP). Die Accounting
definiert einen Satz von Accounting AVPs, die für alle Dienste
genutzt werden, jede Erweiterung bringt aber von sich aus noch ihre
eigene dienstspezifischen Accounting AVPs mit.
RADIUS-Protokoll
Informationen
Erweiterung
Die DIAMETER Accounting Erweiterung bietet eine Echtzeit-Übertragung
der Accounting-Informationen, was besonders in Umgebungen gebraucht
wird, in denen diese Informationen in einem engen Zeitfenster übertragen
werden müssen, wie z.B. bei dem Gebrauch von Kundenkarten.
5. Zusammenfassung
Das Ziel der AAAarch Arbeitsgruppe eine generelle AAA-Architektur zu
etablieren, ist, vor allem im Hinblick auf zukünftige Anwendungsfelder,
sicherlich noch lange nicht erreicht.
RADIUS und DIAMETER, die einzigen wirklichen AAA-Protokolle, die
heutzutage verfügbar sind, wurden für spezielle Anwendungsfälle
konzipiert und leisten die AAA-Dienste mit Hilfe ihrer
Erweiterungsmechanismen.
Neue Entwicklungen, wie die Vernetzung von mobilen Geräten in Ad hoc
Netzwerken oder die dynamischen Netzwerkzugehörigkeit in IP-basierten
Umgebungen bei Mobile-IP, schaffen Voraussetzungen, die von dem
vorgeschlagenen Modell der AAAarch nicht erfüllbar sind.
Insbesondere in Ad hoc Netzwerken, bei denen man durch die
hochdynamische Natur von keiner festen Topologie oder Infrastruktur
ausgehen kann, ist das Modell des AAA-Servers in dieser Form sicherlich
nicht realisierbar und es muss über eine dezentrale Struktur nachgedacht
werden.
Authentifizierung, Autorisierung und Accounting haben in dieser Art von
Netzwerkstruktur neue Probleme und Anforderungen, die in ein
allgemeines Modell mit einfließen müssen, um für die Zukunft gerüstet zu
sein.
6. Quellenverzeichnis
[1]
[2]
[3]
[4]
[5]
Levijoki, „Authentication, Authorisation and Accounting in Ad Hoc
networks”, Helsinki, May 2000
Laat, Gross, Gommans, Vollbrecht, Spence, “Generic AAA
Architecture”, “RFC 2903”, August 2000
Rigney, Livingston, Willens, Rubens Merit, Simpson Daydreamer,
“Remote Authentication Dial In User Service (RADIUS)”, “RFC 2865”,
June 2000
Rigney, Livingston, “RADIUS Accounting”, “RFC 2866”, June 2000
Calhoun, Zorn, Pan, Akhtar, “Diameter Framework”, draft-ietf-aaadiameter-framework-01.txt, March 2001