Inhaltsverzeichnis
Werbung
wenn die Authentifizierung erfolgreich durchgeführt wurde. Diese Bestätigung enthält die Antwort des Servers auf
die Aufforderung des Clients und ermöglicht so eine gegenseitige Authentifizierung.
1
EAP: Der NAS übermittelt den Benutzernamen und eine EAP-Nachricht. Im Gegensatz zu allen vorherigen Methoden
ist EAP nicht zustandslos, d. h. der RADIUS-Server kann mit einer eigenen Aufforderung (Challenge) statt nur mit
einem Access-Accept oder Access-Reject antworten und so weitere Anforderungen vor dem Abschluss der
Authentifizierung stellen. EAP ist selbst ein modulares Authentifizierungsprotokoll, das unterschiedliche
Authentifizierungsverfahren erlaubt.
19.10.3 EAP-Authentifizierung
EAP ist kein festes Authentifizierungsverfahren sondern es bietet einen Rahmen für beliebige Authentifizierungsverfahren.
Der LCOS-RADIUS-Server unterstützt eine Reihe von EAP-Verfahren:
1
EAP/MD5, definiert in RFC 2284. EAP/MD5 ist ein einfaches Challenge/Response-Protokoll. Es erlaubt weder eine
gegenseitige Authentifizierung noch bietet es dynamische Schlüssel an, wie sie für die 802.1x-Authentifizierung in
drahtlosen Netzwerken (WLANs) benötigt werden. Es wird daher nur für die Authentifizierung von nicht-wireless
Clients benötigt oder als getunneltes Verfahren innerhalb von TTLS.
1
EAP/MSCHAPv2, definiert in draft-kamath-pppext-eap-mschapv2-01.txt. Im Gegensatz zu EAP/MD5 erlaubt
EAP/MSCHAPv2 zwar die gegenseitige Authentifizierung, unterstützt aber keine dynamischen Schlüssel und ist daher
ähnlich anfällig für Dictionary Attacks (Wörterbuchattacken) wie EAP/MD5. Dieses Verfahren wird üblicherweise
innerhalb von PEAP-Tunneln genutzt.
1
EAP/TLS, definiert in RFC2716. Der Einsatz von EAP/TLS erfordert ein Root-Zertifikat, eine Geräte-Zertifikat und einen
privaten schlüssel (Private Key) im Gerät. EAP/TLS bietet hervorragende Sicherheit und die für Wireless-Verbindungen
benötigten dynamischen Schlüssel, ist allerdings aufwendig in der Einführung, weil für jeden Client ein Zertifikat und
ein Private Key erstellt werden müssen.
5
Bitte beachten Sie, dass die TLS-Implementation im LCOS weder Zertifikatsketten noch Zertifikats-Rückruflisten
(Certificate Revocation Lists – CRL) unterstützt.
1
EAP/TTLS, definiert in draft-ietf-pppext-eap-ttls-05.txt. TTLS basiert auf TLS, verzichtet aber auf Client-Zertifikate und
verwendet den schon aufgebauten TLS-Tunnel zur Authentifizierung des Clients. Der LCOS-RADIUS-Server unterstützt
die folgenden TTLS-Verfahren:
2
PAP
2
CHAP
2
MSCHAP
2
MSCHAPv2
2
EAP, vorzugsweise EAP/MD5
1
EAP/PEAPv0, definiert in draft-kamath-pppext-peapv0-00.txt. Ähnlich wie TTLS setzt PEAP auf TLS auf und arbeitet
mit einer EAP-Verhandlung im TLS-Tunnel.
5
Bitte beachten sie, dass PEAP zwar beliebige Authentifizierungsverfahren ermöglicht, der LCOS-RADIUS-Server
aber nur MSCHAPv2 als Tunnelmethode unterstützt.
Aktuell kann kein Authentifizierungsverfahren unterdrückt werden – der EAP-Supplicant und der RADIUS-Server handeln
die EAP-Methode über den Standard-EAP-Mechanismus aus. Sollte der Client eine nicht unterstützte EAP-Methode
anfordern, wird er vom RADIUS-Server abgewiesen.
EAP-SIM-Modul im RADIUS-Server
Der RADIUS-Server enthält ein EAP-SIM-Modul, welches das Gerät um die Fähigkeit erweitert, das Home Location Register
(HLR) eines Mobilfunkproviders zu simulieren. Ein HLR generiert in der Regel die nötigen Keys für die registrierten
SIM-Karten, damit ein RADIUS-Server einen Client per EAP-SIM authentifizieren kann.
Die notwendigen Keys lassen sich im RADIUS-Server manuell festlegen und hinterlegen, sodass ein HLR nicht notwendig
ist. EAP-SIM wird z. B. im Zusammenhang mit Hotspot 2.0 verwendet.
Referenzhandbuch
19 Weitere Dienste
1249
Werbung
Inhaltsverzeichnis
