EAP-Authentifizierung

Die Konfiguration der EAP-Authentifizierung erfolgt über RADIUS > Server > Erweiterte Einstellungen > EAP

EAP ist kein festes Authentifizierungsverfahren sondern es bietet einen Rahmen für beliebige Authentifizierungsverfahren.

Default-Methode

Der LCOS-RADIUS-Server unterstützt eine Reihe von EAP-Verfahren:

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.

GTC

Generic Token Card. EAP-GTC ist eine im RFC 3748 definierte EAP-Methode, die auch als PEAPv1 bekannt ist. Sie basiert auf einer von einem Authentifizierungsserver versendeten Text, der von einem Security-Token bearbeitet zurückgeschickt werden muss. Die gesamte Übertragung wird nicht verschlüsselt.

MSCHAPv2

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.

TLS

Definiert in RFC 2716. Der Einsatz von EAP/TLS erfordert ein Root-Zertifikat, ein 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.

Wichtig: Bitte beachten Sie, dass die TLS-Implementation im LCOS weder Zertifikatsketten noch Zertifikats-Rückruflisten (Certificate Revocation Lists – CRL) unterstützt.

TTLS

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:

PAP
CHAP
MSCHAP
MSCHAPv2
EAP, vorzugsweise EAP/MD5

PEAP

Ähnlich wie TTLS setzt PEAP auf TLS auf und arbeitet mit einer EAP-Verhandlung im TLS-Tunnel.

Wichtig: Bitte beachten sie, dass PEAP zwar beliebige Authentifizierungsverfahren ermöglicht, der LCOS-RADIUS-Server aber nur MSCHAPv2 als Tunnelmethode unterstützt.

OTP

One Time Password. Dieser Wert muss bei EAP-OTP für die Zwei-Faktor-Authentifizierung im VPN verwendet werden, da beim LANCOM Advanced VPN-Client die EAP-Methode vom EAP-Server vorgegeben wird.

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.

Tunnel-Server

Um getunnelte EAP Anfragen zu bearbeiten, die für TTLS und PEAP auftreten, geben Sie einfach ein Konto an, dass in der Weiterleitungs-Tabelle gelistet ist. Wählen Sie einen Realm, der keinen Konflikt mit anderen konfigurierten Realms hat. Wenn das Feld leer bleibt, übernimmt der lokale RADIUS-Server die Anfrage selbst. Das bedeutet, die innere und äußere EAP-Phase wird vom lokalen RADIUS-Server durchgeführt.

Bei EAP/TLS den Subject-Namen anhand der RADIUS-Benutzertabelle prüfen

Bei TLS authentifiziert sich der Client alleine über sein Zertifikat. Ist diese Option aktiviert, so prüft der RADIUS-Server zusätzlich, ob der im Zertifikat hinterlegte Benutzername (Common-Name CN im Subject) in der RADIUS-Benutzertabelle enthalten ist. Ist im passenden Eintrag der RADIUS-Benutzertabelle eine VLAN-ID definiert, so wird diese ebenfalls an den Authenticator übermittelt.

Default-Tunnel-Methoden

TTLS-Default / PEAP-Default: Bei der Verwendung von TTLS bzw. PEAP werden zwei Authentifizierungmethoden ausgehandelt. Zunächst wird über EAP ein sicherer TLS-Tunnel ausgehandelt. In diesem Tunnel wird dann wiederum ein zweites Authentifizierungverfahren ausgehandelt. Bei diesen Verhandlungen bietet der Server jeweils ein Verfahren an, welches der Client annehmen (ACK) oder ablehnen (NAK) kann. Lehnt der Client ab, schickt er dem Server einen Vorschlag mit einem Verfahren, welches er gerne nutzen würde. Ist das vom Client vorgeschlagene Verfahren im Server erlaubt, so wird es verwendet, ansonsten bricht der Server die Verhandlung ab. Mit diesem Parameter wird das Verfahren festgelegt, das der Server den Clients als Authentifizierungverfahren im TLS-Tunnel anbieten soll. Durch diese Vorgabe können abgelehnte Vorschläge bei der Verhandlung vermieden und so die Verhandlung beschleunigt werden.

Timouts

Reauth-Periode: Wenn der interne RADIUS-Server auf die Anfrage eines Clients mit einem CHALLENGE antwortet (Verhandlung des Authentifizierungsverfahrens ist noch nicht abgeschlossen), kann der RADIUS-Server dem Authenticator mitteilen, wie lange (in Sekunden) er auf eine Antwort des Clients warten soll, bevor der CHALLENGE erneut zugestellt wird. Durch den Wert 0 wird kein Timeout an den Authenticator übermittelt.
Retransmit-Timeout: Wenn der interne RADIUS-Server auf die Anfrage eines Clients mit einem ACCEPT antwortet (Verhandlung des Authentifizierungsverfahrens ist erfolgreich abgeschlossen), kann der RADIUS-Server dem Authenticator mitteilen, nach welcher Zeit (in Sekunden) er eine erneute Authentifizierung des Clients auslösen soll. Durch den Wert 0 wird kein Timeout an den Authenticator übermittelt.