Management und Wissen

Authentifizierung

Extensible Authentication Protocol

Von Markus Nispel, Dreieich

Die Schwächen im WLAN-Sicherheitsprotokoll WEP bescheren dem Extensible Authentication Protocol (EAP) neue Aufmerksamkeit. EAP ermöglicht eine Nutzerauthentifizierung auf Ebene 2 des OSI-Schichtenmodells und unterstützt dabei vielfältige Mechanismen. Bei entsprechender Konzeption kann EAP letztlich sogar als Vermittler eines netzwerkbasierten Single Sign-on dienen.

Das Extensible Authentication Protocol (EAP) ist ein Mechanismus zur (beidseitigen) Authentifizierung einer Remote-Access-Verbindung. Die genaue Abfolge der Authentifizierung wird zwischen dem so genannten Supplicant (Client) und einem Authenticator (Vermittler zum Server) ausgehandelt. Dabei sind die verschiedensten Mechanismen nutzbar: von Token Cards, über MD5-Challenges hin zu Transport Layer Security (TLS) oder S/Key-Einmalpasswörtern – auch zukünftig zu entwickelnde Verfahren lassen sich integrieren (z. B. kommende biometrische Standards).

Auch mit einem Medium sind dabei mehrere Authentifizierungsebenen möglich. Ein Authenticator kann etwa bei der Verwendung von Security Token Cards nacheinander sowohl den Namen, als auch die PIN als auch den Wert des Tokens separat abfragen und dem Supplicant dabei jeweils einen anderen Authentifizierungs-Status zubilligen.

Weil EAP im OSI-Schichtenmodell bereits in Layer-2-Protokolle eingebettet ist (z. B. in PPP, L2TP oder EAPoL bei 802.1x) ermöglicht es eine Authentifizierung schon bevor die eigentliche "Netzwerk-Verbindung" aufgebaut ist. Die Sicherheitsbarriere greift daher schon sehr früh und damit wesentlich effizienter als Mechanismen, die in höheren Schichten angesiedelt sind.

Die eigentliche Authentifizierung erfolgt durch das Weiterreichen der EAP-Pakete mittels EAP-Radius-Extensions (RFC 2869) an einen Radius-Server. Dieser kann wiederum je nach Hersteller Schnittstellen zu Verzeichnisdiensten wie dem Active Directory von Microsoft oder Novells NDS (z. B. über LDAP oder XML) sowie Plug-ins für eine Secure-ID-Card-Integration unterhalten.

Der Bekanntheits- und Nutzungsgrad des EAP und seiner Varianten steigt zunehmend. Ein Auslöser ist der neue IEEE-Standard 802.1x "port-based Network Authentication", der EAP in der Variante EAPoL beschreibt (EAP over LAN, EAP mit Ethernet Framing). Primär getrieben durch die Anforderungen an Authentifizierung, Verschlüsselung und Schlüsselmanagement im Wireless LAN (WLAN-Standards IEEE 802.11a/b) findet EAP aber zusehends auch Beachtung innerhalb von Ethernet-Netzwerken. Zudem ermöglicht seine Nutzung in der von Microsoft favorisierten VPN-Variante innerhalb von IPSecurity (IPSec) und Layer 2 Tunneling Protocol (L2TP) die einheitliche Authentifizierung eines Nutzers in LAN-, WLAN- und WAN-Infrastrukturen.

Protokollfamilie

Je nach Anforderung und Anwendung können verschiedene EAP-Protokolle zum Einsatz kommen (vgl. Tabelle). EAP-MD5 nutzt eine passwortbasierte Authentifizierung unter Verwendung der MD5-Hashing-Algorithmen. EAP-PEAP arbeitet mit einer Art SSL/TLS-Handshake zum Aufbau einer gesicherten Verbindung, danach erfolgt die Passwortübertragung jedoch mittels Microsofts Challenge-Handshake Authentication Protocol (CHAP, hier in Version 2). Die gängigen Betriebssysteme von Microsoft unterstützen EAP entweder direkt oder über spezielle Treiber von Drittanbietern wie Funk Software ( www.funk.com) oder Meetinghouse Communications ( www.mtghouse.com); eine OpenSource-Initiative zur Implementierung des IEEE 802.1x gibt es ebenfalls schon ( www.open1x.org).

Für WLAN eignet sich im Wesentlichen die Transport-Layer-Security-Implementierung EAP-TLS – nach Abschluss der Arbeiten an dem entsprechenden Standard auch EAP Tunneled TLS (TTLS). Mit EAP-(T)TLS lässt sich ein dynamisches Schlüsselmanagement realisieren, um die Schwächen des WLAN-Sicherheitsprotokolls Wired Equivalent Privacy (WEP) zu beseitigen. Außerdem werden damit dann sowohl Clients als auch Server authentifiziert.

EAP-TTLS wird eine passwortbasierte Authentifizierung für den Client unterstützen (es gibt schon erste Implementierung z. B. von Funk Software). EAP-TLS arbeitet hingegen zertifikatbasiert und stützt sich auf die Nutzung der TLS-Protocol-Suite nach RFC 2246, welche der aktuellen SSL Version 3.0 entspricht (Secure Sockets Layer).

Die Nutzung von Zertifikaten erfordert eine Public Key Infrastructure (PKI) zum Zertifikats-Management sowie zu ihrer Verteilung und Kontrolle. In einer 802.1x-Umgebung kommunizieren die Netzwerkkomponenten zur Authentifizierung mit einem Radius-Server (RFC 2865), welcher die Radius Extensions nach RFC 2869 unterstützt. Dieser ist im Falle von EAP-TLS wiederum an eine PKI angebunden.

EAP-TLS

Bei den verbreiteten SSL-Authentifizierungen zum Aufbau einer https-Verbindung authentifiziert sich meist nur der Server gegenüber dem Client. Dieser überprüft die Identität der Servers und seines Zertifikats anhand einer lokalen Liste von Wurzelzertifikaten der bekannten Zertifizierungsinstanzen (Trusted Root CAs). Der SSL-Handshake läuft bei Web-Anwendungen über TCP. Im Falle von EAP-TLS erfolgt der Handshake über EAP oder EAPoL. EAP-TLS führt zudem eine Authentifizierung sowohl des Clients als auch des Servers durch – genauer gesagt: des Authentication Servers (Radius Server).

Abbildung 1: "Schaltschema" einer EAP-Authentifizierung

Die Anfrage des Client-Systems (Supplicant) läuft dabei über eine Netzwerkkomponente (Authenticator), welche die Prüfung an den eigentlichen Authentication Server vermittelt, der die Authentifizierung durchführt. Nach Start von EAPoL stellt der Authenticator, etwa ein WLAN Access Point, einen Identity Request an den Supplicant. Dieser antwortet mit seiner UserID. Der Authenticator leitet diese dann innerhalb eines Radius Access Requests an den Authentication Server weiter (vgl. Abb. 2).

Abbildung 2: Prinzipieller Ablauf einer EAP-Authentifizierung

Danach erfolgt die eigentliche TLS-Authentifizierung: Der Server sendet sein Zertifikat an den Client und fordert ebenfalls ein Zertifikat vom Supplicant. Nachdem dieser das Server-Zertifikat geprüft hat, sendet er sein eigenes Zertifikat an den Server, der wiederum dessen Überprüfung durchführt. Zudem erfolgt die Aushandlung der sitzungsspezifischen Parameter: Supplicant und Authentication Server ermitteln – wie bei SSL/TLS üblich – unabhängig voneinander parallel den Session Key. Dieser wird vom Authentication Server in Verbindung mit einer Radius-Access-Success-Meldung an den Authenticator weitergegeben.

Die Ermittlung der Session Keys erfolgt über das so genannte Master Secret, das durch eine im TLS RFC 2246 spezifizierte Pseudo-Random Function (PRF) generiert wird. EAP-TLS ermittelt dann aus diesem Master Secret gemäß RFC 2716 den eigentlichen Session Key: Der Client generiert hierzu ein so genanntes Pre-Master Secret und schickt es verschlüsselt mit dem Public Key des Servers an diesen. Zudem generieren und übermitteln Client und Server Zufallszahlen und errechnen aus den vorliegenden Informationen unabhängig über PRF das Master Secret, das somit nie vollständig über die Netzwerkverbindung übertragen wird.

Aus dem Master Secret folgen schließlich (nochmals unter Einbezug von PRF und Zufallszahlen) der eigentliche Session Key, die Schlüssel für den Message Authentication Code (MAC) sowie den Initialization Value für die Block-Verschlüsselung (IV). Die Schlüssellängen legt der Authenticator (Access Point) fest und teilt sie per EAPoL Key Message den Teilnehmern (Supplicants) mit.

Key Management für WLAN

Im WLAN kann nun der Session Key vom Access Point (Authenticator) genutzt werden, um die WEP Encryption Keys für die eigentliche Verbindung verschlüsselt an das Endgerät (Supplicant) zu übertragen. Diese WEP Encryption Keys generiert der Access Point per Zufallsgenerator. Die Übertragung umfasst dann meist separate Sende-/Empfangs-Schlüssel pro Supplicant sowie einen WEP-Schlüssel für Broad-/Multicasts an alle Supplicants einer WLAN-Funkzelle. Diese Schlüssel können auch periodisch im so genannten Rapid-Rekeying-Verfahren getauscht werden. Damit wird Sicherheit sowohl zwischen den Benutzern einer WLAN-Zelle als auch nach außen hin erreicht.

802.1x/EAP-TLS stellt die Basis für fast alle empfohlenen Sicherheitsmaßnahmen der 802.11i dar, etwa für die Mutual Authentication, Dynamic Session Keys, Rapid Rekeying und Message Integrity Checks.

User Personalized Network

Durch die differenzierten Möglichkeiten des EAP lassen sich sowohl in kabelgebundenen als auch in drahtlosen Netzwerken feingranulare Zugriffsrechte umsetzen. Enterasys nennt das in seinen Produkten beispielsweise "User Personalized Network" (UPN). So kann – auch im WLAN – ein für Gäste offenes, aber gleichzeitig strikt beschränktes Netz geschaffen werden: Mitarbeiter erhalten dabei nach der Authentifizierung die ihrem Status entsprechenden Zugriffsrechte auf die Infrastruktur (wohlbemerkt erfolgt die Authentifizierung direkt am Accesspoint und ändert sich pro Benutzer je nach Authentifizierungs-Status). Im gleichen Funknetz bekommen Gäste und Partner des Unternehmens (Consultants, Vertriebsleute oder Entwickler) lediglich bequemen Zugriff auf das Internet oder einige dedizierte Unternehmens-Ressourcen.

Solches "Guest Networking" eignet sich auch als WLAN-Hotspot-Authentifizierung oder im Bereich von Messen. In Verbindung mit der Nutzung von EAP im kabelgebundenen LAN und im VPN erzielt man damit sogar ein netzwerkbasiertes Single Sign-on (SSO), das sich in viele SSO-Ansätze integrieren lässt.

Beispiel eines Netzwerks, in dem EAP Single Sign-on in LAN, WLAN und VPN unterstützt

Fazit

Der Aufbau einer sicheren WLAN-Infrastruktur auf der Basis von IEEE 802.1x eignet sich gut als Start einer einheitlichen Authentifizierungsstrategie im Unternehmensnetz mittels EAP über beliebige Zugangsmedien. Die AAA-Infrastruktur (Accounting, Authentication, Authorization), die für eine WLAN-Umgebung aufgebaut wird, kann unter Umständen nahtlos auch zur LAN- und VPN-Authentifizierung dienen. Neben der erhöhten Zugangskontrolle vermeidet zudem die zentralisierte Verwaltung der Benutzerprofile ein großes Sicherheitsrisiko, das heute noch in vielen Unternehmen besteht: die fehleranfällige und aufwändige verteilte (und evtl. mehrfache) Verwaltung von Benutzerdaten. Eine WLAN-Einführung sollte angesichts dieser Möglichkeiten eine entsprechende Gesamtkonzeption ins Auge fassen.

Dipl.-Ing. Markus Nispel ist Director of Technology bei Enterasys Networks Germany GmbH.

© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 2002/5, Seite 61

Zurück zum Inhalt