Wpa Eap Artikel Revised De Rev2

EAP – Extensible Authentication Protocol

Markus Nispel Office of the CTO [email protected]

Seite 1 von 10 • enterasys Whitepaper

EAP – EXTENSIBLE AUTHENTICATION PROTOCOL ______________________________ 3 1 2 3 4 5 6 7

EINLEITUNG _______________________________________________________________ 3 DIE EAP PROTOKOLLFAMILIE ________________________________________________ 5 PKI INFRASTRUKTUR _______________________________________________________ 6 EAP-TLS (TRANSPORT LAYER SECURITY) ______________________________________ 7 EAP-TLS KEY MANAGEMENT IN WLAN UMGEBUNGEN __________________________ 9 UPN IN EINER WLAN UMGEBUNG ____________________________________________ 10 ZUSAMMENFASSUNG _______________________________________________________ 10

Seite 2 von 10 • enterasys Whitepaper

EAP – Extensible Authentication Protocol Einleitung Der Bekanntheits- und Nutzungsgrad des Protokoll EAP (Extensible Authentication Protocol) und seiner Varianten steigt zunehmend. Auslöser ist ein neuer Standard des IEEE – 802.1x, port-based Network Authentication – der EAP in der Variante EAPoL (EAP over LAN, EAP mit Ethernet Framing) zur Authentisierung beschreibt. Primär getrieben durch die Anforderung bezüglich Authentisierung und Verschlüsselung/Schlüsselmanagement durch die 802.11b und 802.11a WLAN Standards des IEEE bekommt 802.1x und EAP aber zusehends auch Beachtung innerhalb herkömmlicher Ethernet-Netzwerke. Enterasys Networks´ CTO (Chief Technology Officer) als einer der Co-Authoren des Standards 802.1x hat diesen Standard zur Basis der Netzwerk-Architektur von Enterasys Networks unter dem Namen „User Personalized Network“ (UPN) gemacht. UPN verbindet die Benutzer-Authentisierung mittels 802.1x/EAP mit dynamischem Policy Management zur einer einheitlichen AAA (Authentication, Authorization, Accounting) Infrastruktur, die mehr Sicherheit, mehr Mobilität und geringere Betriebskosten über beliebige Zugangsmedien miteinander verbindet. Mehr Informationen finden sie unter www.enterasys.com/upn.

Seite 3 von 10 • enterasys Whitepaper

Die Nutzung von EAP in der von Microsoft favorisierten Variante für VPN (Virtual Private Networks) innerhalb von IPSec/L2TP (IPSecurity, Layer2 Tunneling Protocol) erlaubt eine einheitliche Authentisierung eines Nutzers über LAN, WLAN und WAN Infrastrukturen.

User Personalized Network Single Sign On – Wired, Wireless, VPN

TokenCard or SmartCard

Internet

IPsec/L2TP with EAP

802.1X – with WPA 802.1x - EAPOL RoamAbout R2 AccessPoint

RADIUS – EAP ext.

VPN Tunnel Server

Matrix E7

ANG 7050 Corporate Network

RADIUS – EAP ext. Policy Server Certificate

Radius Server

Authority CA

Seite 4 von 10 • enterasys Whitepaper

Die EAP Protokollfamilie Je nach Anforderung und Anwendung kann man eine Vielzahl von EAP Protokollen zur Anwendung kommen, folgende Tabelle soll eine kurze Übersicht geben: Protokoll

Client/Server Authentisierung

Standard

Dynamisches WEP Schlüsselmanagement

EAP-MD5

RFC 2284

Nein

Nein

EAP-TLS

RFC 2716 draft-ietf-pppext-eap-ttls01.txt draft-josefsson-pppexteap-tls-eap-02.txt

Ja

Ja

Ja

Ja

Ja

Ja

EAP-TTLS EAP-PEAP

Für die Anwendung in WLAN Netzen kann damit heute nur die EAP-TLS (Transport Layer Security) Implementierung empfohlen werden – bei Abschluss des Standards natürlich auch EAP-TTLS (Tunneled TLS) und PEAP. Diese Empfehlung beruht zu Einem auf der Möglichkeit von EAP-(T)TLS, ein dynamisches Schlüsselmanagement zu realisieren (um die Schwächen des dort verwendeten WEP (Wired Equivalent Privacy) im Rahmen der WPA (WiFi Protected Access) zu beseitigen), zum Anderen auf der Tatsache, das sowohl Client als auch Server authentisiert werden können. EAP-TTLS wird eine passwortbasierte Authentisierung für den Client unterstützen (es gibt schon erste Implementierung z.B. von Funk Software). EAP-TLS hingegen ist zertifikats-basiert und stützt sich auf die Nutzung der TLS Protocol-Suite nach RFC 2246, welche der aktuellen SSL Version 3.0 entspricht. EAP-MD5 nutzt eine passwortbasierte Authentisierung, bei welcher MD5 Hashing Algorithmen verwendet werden. EAP-PEAP nutzt eine Art SSL/TLS Handshake zum Aufbau einer gesicherten Verbindung, danach erfolgt die Passwortübertragung mittels MS-CHAPv2. Die gängigen Betriebssysteme von Microsoft unterstützen EAP entweder direkt oder es gibt Treiber von Unternehmen wie Funk Software (www.funk.com) oder Meetinghouse Communications (www.mtghouse.com) – eine OpenSource Initiative gibt es ebenfalls unter www.open1x.org.

Seite 5 von 10 • enterasys Whitepaper

PKI Infrastruktur Die Nutzung von Zertifikaten erfordert eine PKI Infrastruktur (Public Key Infrastruktur) zum Management sowie zur Verteilung und Kontrolle dieser Zertifikate. Ein, von einer sog. Certification Authority (CA), ausgestelltes Zertifikat (CERT) stellt sicher, das der Inhaber dieses Zertifikats – zu welchem ein sog. Public Key gehört – derjenige ist, welcher im Zertifikat benannt ist (Benutzer oder System). Dieser Inhaber besitzt auch den passenden sog. Private Key, um z.B. Nachrichten, die mit seinem Public Key verschlüsselt wurden, auch wieder entschlüsseln zu können. Der Private Key kann auch dazu genutzt werden, um den Sender einer Nachricht eindeutig zu identifizieren – nur der Inhaber des Private Keys kann eine Nachricht so verschlüsseln, dass Sie mit dem Public Key entschlüsselt werden kann. Man kann auch einen Hash-Wert einer Nachricht bilden und diesen Wert mittels seines Private Keys signieren und der Nachricht beilegen. Der Empfänger kann nun die Nachricht mittels des gleichen Hashing Algorithmus bearbeiten, den mit dem Private Key des Senders verschlüsselten Hash Wert mittels des Public Keys entschlüsseln und diese beiden Werte vergleichen – hiermit ist sichergestellt, dass die Nachricht nicht verändert wurde. Das von einer CA ausgestellte Zertifikat für ein System oder einen Benutzer ist z.B. auch mit dem Private Key der CA signiert – damit kann mit dem Public Key der CA geprüft werden, ob das CERT auch wirklich von dieser CA ausgestellt und auch nicht geändert wurde. Die CA steht dafür gerade, dass das Zertifikat auch an den im CERT genannten System oder Benutzer ausgestellt wurde – d.h. es muss eine Vertrauensstellung zur CA vorhanden sein. Damit gibt es in einer PKI Infrastruktur 2 Vertrauensstellungen: Public-Private Key Paar Certification Authority In einer 802.1x Umgebung kommunizieren die Netzwerkkomponenten zur Authentisierung meist mit einem Radius Server (RFC 2865), welcher die Radius Extensions nach RFC 2869 unterstützt. Dieser Server ist im Falle von EAP-TLS wiederum ist an eine PKI Infrastruktur angebunden.

Seite 6 von 10 • enterasys Whitepaper

EAP-TLS (Transport Layer Security) Eine herkömmliche SSL Authentisierung, z.B. bei Aufbau einer https Verbindung, führt nur eine sog. „One-way“ oder „server-side“ Authentication durch. Hierbei authentisiert sich der Server beim Client. Dieser überprüft die Identität der Servers und seines Zertifikats durch den Vergleich der ausstellenden CA der Server-Zertifikats mit einer lokalen Liste von sog. Trusted Root CA´s. Diese Liste, die im Falle einer https Verbindung typischerweise im Browser des Clients gepflegt wird, ist die Certificate Trust List (CTL). Der SSL Handshake wird hier über TCP durchgeführt. Im Falle von EAP-TLS geschieht der Handshake über das EAP bzw. EAPoL Protokoll. EAP-TLS führt im Gegensatz zum SSL Handshake eine Authentisierung sowohl des Clients als auch des Servers (genauer gesagt: des Authentication Servers, oft ein Radius Server) durch.

EAP- Authentication Exchange Switch Port

Supplicant PAE (user)

Authentication Server (RADIUS)

Authenticator System Services Port unauthorized

Authenticator PAE

EAPOL Exchange

LAN EAP arbeitet hier hierbei mit folgenden Bezeichnungen: Supplicant – das Client System Authenticator – die Netzwerkkomponente, welche die Authentisierung weiterleitet Authentication Server – die Komponente, welche die Authentisierung durchführt

Seite 7 von 10 • enterasys Whitepaper

Die logische Abfolge eine EAP Authentisierung sieht dann wie folgt aus:

EAP-TLS Authentication Authenticator

Supplicant WLAN

Authentication (RADIUS) Server

derive and pass session key to AP

derive session key

!

WEP Keys delivered, with Session Key protected

Nach dem EAPoL Start stellt der Authenticator, in diesem Fall der WLAN Access Point, einen Identity Request an den Supplicant. Dieser antwortet mit seiner UserID. Der Authenticator leitet dies innerhalb eines Radius Access Requests an den Authentication Server weiter. Danach erfolgt die eigentliche TLS Authentisierung: 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 eine Überprüfung durchführt. Es erfolgt ebenfalls die Aushandlung der session-spezifischen Parameter. Parallel ermitteln Supplicant und Authentication Server unabhängig voneinander den Session Key. Dieser wird vom Authentication Server in Verbindung mit einer Radius Access Success Meldung an den Authenticator weitergegeben.

Seite 8 von 10 • enterasys Whitepaper

EAP-TLS Key Management in WLAN Umgebungen Da in diesem Beispiel WLAN als Medium genutzt wird, kann der Session Key nun vom Authenticator, dem WLAN Access Point genutzt werden, um die WEP Encryption Keys für die eigentliche Verbindung verschlüsselt an den Supplicant zu übertragen. Die WEP Encryption Keys werden per Zufallsgenerator im Access Point generiert. Die Übertragung beinhaltet dann meist separate WEP Sende/Empfangs-Schlüssel pro Supplicant sowie einen WEP Schlüssel für Broad-/Multicasts für alle Supplicants einer WLAN Funkzelle. Diese Schlüssel können kann auch periodisch über sog. Rapid Rekeying Verfahren getauscht werden. Damit wird eine Sicherheit sowohl zwischen den Benutzern in einer WLAN Funkzelle als auch und insbesondere nach außen hin erreicht. Rapid Rekeying ist integriert im TKIP (Temporal Key Integrity Protocol) des WiFi Standards WPA – der Nachfolger des WEP. Die Ermittlung des Session Keys erfolgt über das Master Secret, welches in der im TLS RFC 2246 spezifizierten „pseudo-random function“ PRF generiert wird. EAP-TLS RFC 2716 ermittelt dann aus diesem Master Secret den eigentlichen Session Key. Dies geschieht folgendermaßen: Der Client generiert ein sog. Pre-Master Secret, verschlüsselt dies mit dem Public Key des Servers und schickt es an diesen. Neben diesem Pre-Master Secret werden Zufallszahlen auf Client- und Server-Seite generiert, zusammen wird über PRF das Master Secret ermittelt. Dieses wiederum wird nochmals mit PRF und den Zufallszahlen des Clients und Servers dazu genutzt, um den eigentlichen Session Key, die MAC (Message Authentication Code) Keys sowie den IV (Initialization Value, für Block Codes) zu ermitteln. Die Keys werden von Server und Client unabhängig ermittelt, die Key-Länge wird jedoch vom Authenticator (Access Point) festgelegt und per EAPoL Key Message übertragen. Insbesondere für WLAN Umgebungen ist die Nutzung von EAP-TLS/TTLS oder PEAP im Rahmen von 802.1x sehr empfehlenswert, abzuleiten aus den empfohlenen Maßnahmen der Arbeitsgruppe 802.11i Security Task Group und des WiFi WPA Standards: • • • •

Mutual (Client/Server) Authentication Dynamic Session Key Message Integrity Check (MIC) Temporal Key Integrity Protocol (TKIP) o Per Paket Key hashing o Initialization Vector Sequencing o Rapid Rekeying RrK

802.1x stellt für fast alle Maßnahmen der 802.11i und des WPA die Basis dar, sowohl bei der Mutual Authentication, als auch beim Dynamic Session Key, Rapid Rekeying sowie beim Message Integrity Check. Eine Preshared Key Variante ist vom Administrationsaufwand kaum zu handhaben.

Seite 9 von 10 • enterasys Whitepaper

UPN in einer WLAN Umgebung Die WLAN Produkte der Roamabout Serie von Enterasys Networks unterstützen neben den zuvor genannten Funktionen auch die Architektur „User Personalized Network“ – genauso wie die LAN Switch und Routerprodukte. Im Bereich WLAN kann UPN z.B. ein sog. „Guest Networking“ bereitstellen: Mitarbeiter eines Unternehmens bekommen nach der Authentisierung volle bzw. auf Ihren Status bezogene Zugriffsrechte auf die Infrastruktur – die Ausführung dieser Zugriffsrechte erfolgt direkt am Accesspoint und ändert sich pro Benutzer je nach Authentisierungs-Status. Gäste des Unternehmens wie Consultants, Vertriebs- oder Entwicklungspartner bekommen über WLAN ausschließlich Zugriff auch den InternetZugang oder einige dedizierte Ressourcen des Unternehmens. Diese Funktion kann dynamisch und ohne weitere Administration bereitgestellt werden. Auch eignet sich „Guest Networking“ als WLAN Hotspot Technologie oder im Bereich von MesseBetreibern etc.

Zusammenfassung Der Aufbau einer sicheren WLAN Infrastruktur auf der Basis von 802.1x wird der Start einer einheitlichen Authentisierungsstrategie mittels EAP über beliebige Zugangsmedien in den Unternehmensnetzen sein. Die AAA Infrastruktur, die für eine WLAN Umgebung aufgebaut wird, kann danach nahtlos auch für LAN und auch VPN Authentisierung genutzt werden. Neben der erhöhten Zugangskontrolle an sich schließt alleine die zentralisierte Verwaltung der Benutzerprofile eine große Sicherheitslücke in heutigen Unternehmen, nämlich die verteilte und mehrfache Verwaltung von Benutzerdaten. In Anbetracht dieser Möglichkeiten sollte daher eine Einführung von WLAN immer einhergehen mit der Betrachtung dieser Möglichkeiten und damit natürlich mit einer Konzeption, die eine einfache Erweiterung in diese Richtung ermöglicht.

Seite 10 von 10 • enterasys Whitepaper