WLAN und LAN sichern mit IEEE 802.1X und Radius
Seite 2: EAP-Varianten
Lightweight EAP
LEAP ist eine von Cisco Systems entworfene EAP-Variante. Zwar legt Cisco keine Details offen, aber eine ausführliche Beschreibung des Protokolls auf Basis von Netzwerkanalysen wurde in einer Mailingliste veröffentlicht.
Das Prinzip ist simpel: Der Peer authentifiziert sich durch einen Challenge auf Basis eines Shared Secret, das sowohl der Peer als auch der Radius-Server kennen. Umgekehrt kann der Peer die Echtheit seines Authenticators über ein digitales Zertifikat überprüfen. LEAP ist aber anfällig für Wörterbuch-Attacken, wie Cisco selbst zugibt.
Der von Cisco vorangetriebene LEAP-Nachfolger EAP-FAST (Flexible Authentication via Secure Tunneling, RFC 4851) adressiert die bekannten Schwachstellen, schafft aber neue Angriffsmöglichkeiten.
EAP mit Transport Layer Security
Gegenseitige Authentifizierung von Peer und Authenticator mit digitalen Zertifikaten und Schlüsselmanagement bringt die EAP-Erweiterung TLS (RFC 5246). TLS nutzt ein asymmetrisches Chiffrierverfahren zum Ermitteln der Sitzungsschlüssel. Zu Beginn schickt der Authenticator sein Zertifikat zusammen mit seinem öffentlichen Schlüssel (Public Key) und fordert den Peer auf, das gleiche zu tun. Der Peer antwortet entsprechend und generiert anschließend ein Premaster Secret, das er mit dem Public Key des Authenticators verschlüsselt und abschickt. Aus dem Premaster Secret leitet der Authenticator dann ein Master Secret ab, mit dem er neue Schlüssel erzeugt, die beispielsweise als dynamische Sitzungsschlüssel dienen können.
Hat der Peer das Zertifikat des Authenticators über einen sicheren Kanal erhalten oder kann er dessen Gültigkeit über ein Stammzertifikat einer Certification Authority (CA) überprüfen, dann ist diese EAP-Variante die sicherste von allen. EAP-TLS wird in RFC 5216 beschrieben.
EAP mit Tunneled TLS
EAP-TTLS stellt eine Variante zu EAP-TLS dar, die bei der Überprüfung des Peers anders vorgeht. Zunächst authentifiziert sich der Authenticator durch Versenden seines Zertifikats gegenüber dem Peer. Bei erfolgreicher Authentifizierung baut Letzterer einen sicheren TLS-Tunnel zum Authenticator auf und authentifiziert sich seinerseits. Diese Authentifizierung kann sowohl mit einem Zertifikat als auch mit anderen EAP-Mechanismen (MD5-Challenge, One-Time Password) stattfinden. Wie EAP-TLS unterstützt auch EAP-TTLS das dynamische Generieren von Sitzungsschlüsseln.
Derzeit gängig ist EAP-TTLSv0 (RFC 5281). Die Variante EAP-TTLSv1 liegt bislang nur als Entwurf vor. Sie verwendet die TLS-Erweiterung TLS/IA (Inner Application), mit der Authentifizierung und Parameterübergabe zwischen Client und Server innerhalb des TLS-Steuerungskanals laufen können. Bei EAP-TTLSv0 geschehen diese Dinge im Datenkanal. TLS/IA soll unter anderem die Sicherheit gegen Man-in-the-Middle-Angriffe auf Tunneled Authentication verbessern.
Protected EAP
Das von Microsoft gemeinsam mit Cisco und RSA Security entwickelte PEAP existiert in mehreren Versionen, die alle noch IETF-Entwurfsstatus haben, zuletzt PEAPv2. Es kam erstmals mit Windows XP zu breitem Einsatz. Protected EAP ähnelt EAP-TTLS sehr stark: Es baut nach der Authentifizierung des Authenticators zunächst einen sicheren Kanal via TLS auf, über den sich dann der Peer gegenüber dem Authenticator authentifiziert.
Im Unterschied zu EAP-TTLS findet zur Authentifizierung des Peers jetzt eine eigene EAP-Sitzung statt, bei der die jeweils unterstützten Authentifizierungsmechanismen benutzt werden können. Auch PEAP kann dynamische Sitzungsschlüssel erzeugen.
EAP-IKEv2
Als jüngste Variante ist EAP-IKEv2 (RFC 5106) erschienen. Es nutzt das von IPsec bekannte Internet-Key-Exchange-Protokoll v2 zur gegenseitigen Authentifizierung. Bisher ist nur eine prototypische Implementierung bekannt.
