Sie sind auf Seite 1von 10
EAP – Extensible Authentication Protocol Markus Nispel Office of the CTO markus.nispel@enterasys.com Seite 1 von

EAP – Extensible Authentication Protocol

Markus Nispel Office of the CTO markus.nispel@enterasys.com

Protocol Markus Nispel Office of the CTO markus.nispel@enterasys.com Seite 1 von 10 • enterasys Whitepaper
EAP – EXTENSIBLE AUTHENTICATION PROTOCOL 3 1 E INLEITUNG 3 2 D IE EAP P

EAP – EXTENSIBLE AUTHENTICATION PROTOCOL

3

1 EINLEITUNG

3

2 DIE EAP PROTOKOLLFAMILIE

5

3 PKI INFRASTRUKTUR

6

4 EAP-TLS (TRANSPORT LAYER SECURITY)

7

5 EAP-TLS KEY MANAGEMENT IN WLAN UMGEBUNGEN

9

6 UPN IN EINER WLAN UMGEBUNG

10

7 ZUSAMMENFASSUNG

10

EAP – Extensible Authentication Protocol Einleitung Der Bekanntheits- und Nutzungsgrad des Protokoll EAP (Extensible

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.

Die Nutzung von EAP in der von Microsoft favorisierten Variante für VPN (Virtual Private Networks)

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

Network Single Sign On – Wired, Wireless, VPN TokenCard or SmartCard IPsec/L2TP with EAP Internet VPN

TokenCard or SmartCard

Sign On – Wired, Wireless, VPN TokenCard or SmartCard IPsec/L2TP with EAP Internet VPN Tunnel Server
Sign On – Wired, Wireless, VPN TokenCard or SmartCard IPsec/L2TP with EAP Internet VPN Tunnel Server
IPsec/L2TP with EAP Internet VPN Tunnel Server
IPsec/L2TP with EAP
Internet
VPN Tunnel
Server

ANG 7050

Corporate

Network

802.1X – with WPA
802.1X – with WPA
Server ANG 7050 Corporate Network 802.1X – with WPA RoamAbout R2 AccessPoint RADIUS – EAP ext.

RoamAbout R2

AccessPoint

Network 802.1X – with WPA RoamAbout R2 AccessPoint RADIUS – EAP ext. Certificate Radius Server 802.1x
Network 802.1X – with WPA RoamAbout R2 AccessPoint RADIUS – EAP ext. Certificate Radius Server 802.1x

RADIUS – EAP ext.

– with WPA RoamAbout R2 AccessPoint RADIUS – EAP ext. Certificate Radius Server 802.1x - EAPOL
Certificate
Certificate
WPA RoamAbout R2 AccessPoint RADIUS – EAP ext. Certificate Radius Server 802.1x - EAPOL Matrix E7
WPA RoamAbout R2 AccessPoint RADIUS – EAP ext. Certificate Radius Server 802.1x - EAPOL Matrix E7

Radius

Server

802.1x - EAPOL

Matrix E7

EAP ext. Certificate Radius Server 802.1x - EAPOL Matrix E7 Policy Server RADIUS – EAP ext.
EAP ext. Certificate Radius Server 802.1x - EAPOL Matrix E7 Policy Server RADIUS – EAP ext.

Policy Server

RADIUS – EAP ext.

Authority CA

Die EAP Protokollfamilie Je nach Anforderung und Anwendung kann man eine Vielzahl von EAP Protokollen

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:

   

Client/Server

Dynamisches WEP Schlüsselmanagement

Protokoll

Standard

Authentisierung

EAP-MD5

RFC 2284

Nein

Nein

EAP-TLS

RFC 2716

Ja

Ja

 

draft-ietf-pppext-eap-ttls

   

EAP-TTLS

01.txt

Ja

Ja

 

draft-josefsson-pppext-

   

EAP-PEAP

eap-tls-eap-02.txt

Ja

Ja

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.

PKI Infrastruktur Die Nutzung von Zertifikaten erfordert eine PKI Infrastruktur (Public Key Infrastruktur) zum Management

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.

EAP-TLS (Transport Layer Security) Eine herkömmliche SSL Authentisierung, z.B. bei Aufbau einer https Verbindung, führt

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 Authenticator System EAPOL Services Authenticator Exchange PAE Port unauthorized LAN
Switch Port
Authenticator System
EAPOL
Services
Authenticator
Exchange
PAE
Port unauthorized
LAN

Authentication

Server

(RADIUS)

Supplicant

PAE

(user)

LAN Authentication Server (RADIUS) Supplicant PAE (user) EAP arbeitet hier hierbei mit folgenden Bezeichnungen:

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

Die logische Abfolge eine EAP Authentisierung sieht dann wie folgt aus: EAP-TLS Authentication Supplicant WLAN

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

EAP-TLS Authentication

Supplicant

sieht dann wie folgt aus: EAP-TLS Authentication Supplicant WLAN Authenticator Authentication (RADIUS) Server derive
sieht dann wie folgt aus: EAP-TLS Authentication Supplicant WLAN Authenticator Authentication (RADIUS) Server derive
WLAN
WLAN

Authenticator

aus: EAP-TLS Authentication Supplicant WLAN Authenticator Authentication (RADIUS) Server derive session key derive and

Authentication

(RADIUS) Server

derive

session key

derive and pass session key to AP ! WEP Keys delivered, with Session Key protected
derive and
pass session
key to AP
!
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.

EAP-TLS Key Management in WLAN Umgebungen Da in diesem Beispiel WLAN als Medium genutzt wird,

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.

UPN in einer WLAN Umgebung Die WLAN Produkte der Roamabout Serie von Enterasys Networks unterstützen

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 Internet- Zugang 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 Messe- Betreibern 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.