Extensible Authentication Protocol - Wikipedia

Extensible Authentication Protocol ( EAP ) ist ein Authentifizierungs-Framework, das häufig in drahtlosen Netzwerken und Punkt-zu-Punkt-Verbindungen verwendet wird. Es ist in RFC 3748 definiert, das RFC 2284 überflüssig machte, und wird von RFC 5247 aktualisiert.

EAP ist ein Authentifizierungs-Framework zum Bereitstellen des Transports und der Verwendung von Schlüsselmaterial und Parametern, die von EAP-Methoden generiert werden. ^[1] Es gibt viele von RFCs definierte Methoden und eine Reihe von anbieterspezifischen Methoden, und es gibt neue Vorschläge. EAP ist kein Drahtprotokoll. Stattdessen werden nur Nachrichtenformate definiert. Jedes Protokoll, das EAP verwendet, definiert eine Methode zum Einkapseln von EAP-Nachrichten in den Nachrichten dieses Protokolls.

EAP ist weit verbreitet. Zum Beispiel haben die Standards WPA und WPA2 in IEEE 802.11 (WiFi) IEEE 802.1X mit einhundert EAP-Typen als offizielle Authentifizierungsmechanismen übernommen.

Methods [ edit ]

EAP ist ein Authentifizierungs-Framework und kein spezifischer Authentifizierungsmechanismus. ^[1] Es bietet einige allgemeine Funktionen und Aushandlung von Authentifizierungsmethoden, die als EAP-Methoden bezeichnet werden. Derzeit sind etwa 40 verschiedene Methoden definiert. In IETF-RFCs definierte Methoden umfassen EAP-MD5, EAP-POTP, EAP-GTC, EAP-TLS, EAP-IKEv2, EAP-SIM, EAP-AKA und EAP-AKA '. Darüber hinaus gibt es eine Reihe herstellerspezifischer Methoden und neue Vorschläge. Häufig verwendete moderne Methoden, die in drahtlosen Netzwerken eingesetzt werden können, umfassen EAP-TLS, EAP-SIM, EAP-AKA, LEAP und EAP-TTLS. Die Anforderungen an EAP-Methoden für die WLAN-Authentifizierung werden in RFC 4017 beschrieben. Die Liste der in EAP verwendeten Typen- und Paketcodes ist in der IANA EAP-Registry verfügbar.

Der Standard beschreibt auch die Bedingungen, unter denen die in RFC 4962 beschriebenen AAA-Schlüsselverwaltungsanforderungen erfüllt werden können.

Flinke Out-of-Band-Authentifizierung für EAP (EAP-NOOB) [ edit ]

Flinke Out-of-Band-Authentifizierung für EAP (EAP-NOOB) hat eine offene Quelle Implementierung. Im Gegensatz zu anderen EAP-Methoden wurde die Protokollsicherheit durch formale Modellierung der Spezifikation mit ProVerif- und MCRL2-Tools verifiziert. ^[2]

LEAP (Lightweight Extensible Authentication Protocol) [ edit ]

The Lightweight Das LEAP-Verfahren (Extensible Authentication Protocol) wurde von Cisco Systems vor der IEEE-Ratifizierung des Sicherheitsstandards 802.11i entwickelt. ^[3] Cisco verteilte das Protokoll über CCX (Cisco Certified Extensions) als Teil der Einführung von 802.1X und dynamischer WEP die Industrie in Abwesenheit eines Standards. LEAP wird von keinem Windows-Betriebssystem aus nativ unterstützt, wird jedoch von Client-Software von Drittanbietern unterstützt, die meistens in WLAN-Geräten enthalten ist. LEAP-Unterstützung für Microsoft Windows 7 und Microsoft Windows Vista kann hinzugefügt werden, indem ein Client-Add-In von Cisco heruntergeladen wird, das sowohl LEAP als auch EAP-FAST unterstützt. Aufgrund der breiten Verbreitung von LEAP in der Netzwerkbranche fordern viele andere WLAN-Anbieter ^{[ wer?} Unterstützung für LEAP.

LEAP verwendet eine modifizierte Version von MS-CHAP, ein Authentifizierungsprotokoll, in dem Benutzeranmeldeinformationen nicht stark geschützt und leicht gefährdet sind. Ein Exploit-Tool namens ASLEAP wurde Anfang 2004 von Joshua Wright veröffentlicht. ^[4] Cisco empfiehlt Kunden, die LEAP unbedingt verwenden müssen, dies nur mit ausreichend komplexen Passwörtern, obwohl komplexe Passwörter nur schwer zu verwalten und durchzusetzen sind. Ciscos aktuelle Empfehlung lautet, neuere und stärkere EAP-Protokolle wie EAP-FAST, PEAP oder EAP-TLS zu verwenden.

EAP-Transportschichtsicherheit (EAP-TLS) [ edit ]

EAP-Transportschichtsicherheit (EAP-TLS), definiert in RFC 5216, ist ein offener IETF-Standard, der den EET-Standard verwendet Transport Layer Security (TLS) -Protokoll und wird von Mobilfunkanbietern gut unterstützt. EAP-TLS ist das ursprüngliche Standardprotokoll für die drahtlose LAN-EAP-Authentifizierung.

EAP-TLS gilt nach wie vor als einer der sichersten verfügbaren EAP-Standards. TLS bietet jedoch nur dann eine hohe Sicherheit, wenn der Benutzer potenzielle Warnungen über falsche Anmeldeinformationen kennt und von allen Herstellern von Wireless-LAN-Hardware und -Software universell unterstützt wird. Bis April 2005 war EAP-TLS der einzige EAP-Anbieter, der für die Zertifizierung eines WPA- oder WPA2-Logos erforderlich war. ^[5] Es gibt Client- und Serverimplementierungen von EAP-TLS in 3Com, Apple, Avaya, Brocade Communications, Cisco und Enterasys Networks , Foundry, Hirschmann, HP, Juniper, Microsoft und Open Source-Betriebssysteme. EAP-TLS wird in Mac OS X 10.3 und höher, wpa_supplicant, Windows 2000 SP4, Windows XP und höher, Windows Mobile 2003 und höher, Windows CE 4.2 und Apples iOS-Betriebssystem von Windows nativ unterstützt.

Im Gegensatz zu den meisten TLS-Implementierungen von HTTPS, wie z. B. im World Wide Web, erfordern die meisten EAP-TLS-Implementierungen clientseitige X.509-Zertifikate, ohne dass die Option zum Deaktivieren der Anforderung besteht, auch wenn der Standard dies nicht verlangt ihre Verwendung. ^[6][7] Einige haben festgestellt, dass dies das Potenzial hat, die Einführung von EAP-TLS drastisch zu reduzieren und "offene", aber verschlüsselte Zugangspunkte zu verhindern. ^[6][7] Am 22. August 2012 fügten hostapd (und wpa_supplicant) Unterstützung in seinem Git-Repository hinzu für einen herstellerspezifischen UNAUTH-TLS-EAP-Typ (unter Verwendung des RFC 5612-Projekts für private Unternehmen unter Verwendung des hostapd / wpa_supplicant-Projekts) ^[8] und am 25. Februar 2014 Unterstützung für den herstellerspezifischen WFA-UNAUTH-TLS-EAP-Typ (unter Verwendung des Wi -Fi Alliance Private Enterprise Number), ^[9][10] die nur die Serverauthentifizierung durchführen. Dies würde Situationen wie bei HTTPS ermöglichen, in denen ein drahtloser Hotspot freien Zugriff ermöglicht und Stationsclients nicht authentifiziert. Stationsclients möchten jedoch Verschlüsselung verwenden (IEEE 802.11i-2004, d. H. WPA2) und den drahtlosen Hotspot möglicherweise authentifizieren. Es wurde auch vorgeschlagen, IEEE 802.11u für Zugangspunkte zu verwenden, um zu signalisieren, dass sie EAP-TLS nur mit serverseitiger Authentifizierung zulassen, wobei der Standard-EAP-TLS-IETF-Typ anstelle eines herstellerspezifischen EAP-Typs verwendet wird. ^[11]

Die Anforderung an ein clientseitiges Zertifikat, so unpopulär es auch sein mag, gibt EAP-TLS seine Authentifizierungsstärke und verdeutlicht den klassischen Kompromiss zwischen Komfort und Sicherheit. Bei einem clientseitigen Zertifikat reicht ein kompromittiertes Kennwort nicht aus, um in EAP-TLS-fähige Systeme einzudringen, da der Eindringling noch das clientseitige Zertifikat besitzen muss. In der Tat ist nicht einmal ein Kennwort erforderlich, da es nur dazu dient, das clientseitige Zertifikat für die Speicherung zu verschlüsseln. Die höchste verfügbare Sicherheit ist, wenn die "privaten Schlüssel" eines clientseitigen Zertifikats in Chipkarten untergebracht sind. ^[12] Dies ist so, weil es keine Möglichkeit gibt, den entsprechenden privaten Schlüssel eines clientseitigen Zertifikats von einer Chipkarte zu stehlen, ohne die Karte zu stehlen selbst. Es ist wahrscheinlicher, dass der physische Diebstahl einer Chipkarte bemerkt wird (und die Chipkarte sofort widerrufen wird) als ein (typischer) Passwortdiebstahl. Darüber hinaus wird der private Schlüssel auf einer Smartcard in der Regel mit einer PIN verschlüsselt, die nur dem Besitzer der Smartcard bekannt ist. Dadurch wird der Nutzen für einen Dieb auf ein Minimum reduziert, noch bevor die Karte als gestohlen und gesperrt gemeldet wurde.

EAP-MD5 [ edit ]

EAP-MD5 war das einzige auf IETF Standards Track basierende EAP-Verfahren, als es erstmals in der ursprünglichen RFC für EAP, RFC 2284, definiert wurde. Es bietet minimale Sicherheit; Die MD5-Hash-Funktion ist anfällig für Wörterbuchangriffe und unterstützt keine Schlüsselgenerierung, was sie für die Verwendung mit dynamischem WEP oder WPA / WPA2-Unternehmen ungeeignet macht. EAP-MD5 unterscheidet sich von anderen EAP-Methoden dadurch, dass es nur die Authentifizierung des EAP-Peers beim EAP-Server ermöglicht, nicht jedoch die gegenseitige Authentifizierung. Da keine EAP-Serverauthentifizierung bereitgestellt wird, ist diese EAP-Methode für Man-in-the-Middle-Angriffe anfällig. ^[13] Die EAP-MD5-Unterstützung wurde zuerst in Windows 2000 enthalten und in Windows Vista nicht mehr weiterentwickelt. ^[14]

EAP-geschütztes Einmalpasswort (EAP-POTP) [ edit ]

Das EAP-geschützte Einmalpasswort (EAP-POTP), das in RFC 4793 beschrieben wird, ist eine von RSA Laboratories entwickelte EAP-Methode, die ein solches verwendet OTP-Token (Time Password), wie z. B. ein Handheld-Hardwaregerät oder ein Hardware- oder Softwaremodul, das auf einem PC ausgeführt wird, um Authentifizierungsschlüssel zu generieren. EAP-POTP kann verwendet werden, um einseitige oder gegenseitige Authentifizierung und Schlüsselmaterial in Protokollen bereitzustellen, die EAP verwenden.

Die EAP-POTP-Methode bietet eine Zwei-Faktor-Benutzerauthentifizierung, was bedeutet, dass ein Benutzer sowohl physischen Zugriff auf ein Token als auch Kenntnis einer persönlichen Identifikationsnummer (PIN) benötigt, um die Authentifizierung durchzuführen. ^[15]

EAP-Pre-Shared Key (EAP) -PSK) [ edit ]

Der in RFC 4764 definierte EAP-Pre-Shared-Key (EAP-PSK) ist eine EAP-Methode für die gegenseitige Authentifizierung und die Ableitung des Sitzungsschlüssels unter Verwendung eines Pre-Shared Schlüssel (PSK). Bei erfolgreicher gegenseitiger Authentifizierung stellt es einen geschützten Kommunikationskanal für die Kommunikation beider Parteien bereit und ist für die Authentifizierung über unsichere Netzwerke wie IEEE 802.11 ausgelegt.

EAP-PSK ist in einem experimentellen RFC dokumentiert, der eine einfache und erweiterbare EAP-Methode bereitstellt, für die keine Kryptografie mit öffentlichen Schlüsseln erforderlich ist. Der Protokollaustausch der EAP-Methode erfolgt in mindestens vier Nachrichten.

EAP-Kennwort (EAP-PWD) [ edit ]

Das in RFC 5931 definierte EAP-Kennwort (EAP-PWD) ist eine EAP-Methode, die zur Authentifizierung ein gemeinsames Kennwort verwendet. Das Passwort kann ein niedriges Entropie-Passwort sein und kann aus einem Satz möglicher Passwörter gezogen werden, beispielsweise aus einem Wörterbuch, das einem Angreifer zur Verfügung steht. Der zugrunde liegende Schlüsselaustausch ist resistent gegen aktive Angriffe, passive Angriffe und Wörterbuchangriffe.

EAP-PWD befindet sich in der Basis von Android 4.0 (ICS), es befindet sich in RADIUS-Servern FreeRADIUS ^[16] und Radiator ^[17] und es ist in hostapd und wpa_supplicant. ^[18]

EAP-Tunneled Transport Layer Security (EAP) -TTLS) [ edit ]

EAP-Tunneled Transport Layer Security (EAP-TTLS) ist ein EAP-Protokoll, das TLS erweitert. Es wurde von Funk Software und Certicom mitentwickelt und wird plattformübergreifend unterstützt. Microsoft hat die native Unterstützung für das EAP-TTLS-Protokoll in Windows XP, Vista oder 7 nicht integriert. Die Unterstützung von TTLS auf diesen Plattformen erfordert von ECP (Encryption Control Protocol) zertifizierte Software von Drittanbietern. Microsoft Windows hat die EAP-TTLS-Unterstützung mit Windows 8 gestartet ^[19] jedoch unterstützt Windows Phone 8 EAP-TTLS ^[20] nicht, während Version 8.1 dies unterstützt. ^[21]

Der Client kann, Es muss jedoch nicht über ein von der CA signiertes PKI-Zertifikat beim Server authentifiziert werden. Dies vereinfacht die Einrichtung erheblich, da nicht auf jedem Client ein Zertifikat benötigt wird.

Nachdem der Server über sein CA-Zertifikat und optional der Client beim Server sicher beim Client authentifiziert wurde, kann der Server die hergestellte sichere Verbindung ("Tunnel") zur Authentifizierung des Clients verwenden. Es kann ein vorhandenes und weit verbreitetes Authentifizierungsprotokoll und -infrastruktur verwenden, das ältere Kennwortmechanismen und Authentifizierungsdatenbanken enthält, während der sichere Tunnel Schutz vor Abhören und Man-in-the-Middle-Angriffen bietet. Beachten Sie, dass der Name des Benutzers niemals unverschlüsselt in Klartext übertragen wird, um die Privatsphäre zu verbessern.

Es gibt zwei verschiedene Versionen von EAP-TTLS: Original EAP-TTLS (auch bekannt als EAP-TTLSv0) und EAP-TTLSv1. EAP-TTLSv0 ist in RFC 5281 beschrieben, EAP-TTLSv1 ist als Internetentwurf verfügbar. ^[22]

EAP Internet Key Exchange v. 2 (EAP-IKEv2) [ edit ]

EAP Internet Key Exchange v. 2 (EAP-IKEv2) ist eine EAP-Methode, die auf dem Internet Key Exchange-Protokoll Version 2 (IKEv2) basiert. Es bietet gegenseitige Authentifizierung und die Einrichtung eines Sitzungsschlüssels zwischen einem EAP-Peer und einem EAP-Server. Es unterstützt Authentifizierungstechniken, die auf den folgenden Arten von Anmeldeinformationen basieren:

Asymmetrische Schlüsselpaare

Öffentliche / private Schlüsselpaare, bei denen der öffentliche Schlüssel in ein digitales Zertifikat eingebettet ist und der entsprechende private Schlüssel nur einer einzelnen Partei bekannt ist.

Kennwörter

Bitstrings mit niedriger Entropie Dies sind sowohl dem Server als auch dem Peer bekannt.

Symmetrische Schlüssel

Bit-Strings mit hoher Entropie, die sowohl dem Server als auch dem Peer bekannt sind.

Es ist möglich, einen anderen Authentifizierungsnachweis (und damit Technik) in jede Richtung. Beispielsweise authentifiziert sich der EAP-Server mit einem öffentlichen / privaten Schlüsselpaar und der EAP-Peer mit einem symmetrischen Schlüssel. In der Praxis werden insbesondere folgende Kombinationen erwartet:

EAP-Server	EAP-Peer
Asymmetrisches Schlüsselpaar	Asymmetrisches Schlüsselpaar
	Symmetrischer Schlüssel
	Passwort
Symmetrischer Schlüssel	Symmetrischer Schlüssel

EAP-IKEv2 wird in RFC 5106 beschrieben, und es existiert eine Prototypimplementierung.

EAP-flexible Authentifizierung über sicheres Tunneling (EAP-FAST) [ edit ]

Flexible Authentifizierung über sicheres Tunneling (EAP-FAST; RFC 4851) ist ein Protokollvorschlag von Cisco Systems as ein Ersatz für LEAP. ^[23] Das Protokoll wurde entwickelt, um die Schwachstellen von LEAP anzugehen und gleichzeitig die "leichte" Implementierung zu erhalten. Die Verwendung von Serverzertifikaten ist in EAP-FAST optional. EAP-FAST verwendet PAC (Protected Access Credential) zum Erstellen eines TLS-Tunnels, in dem Client-Anmeldeinformationen überprüft werden.

EAP-FAST besteht aus drei Phasen: ^[24]

Phase	Funktion	Beschreibung	Zweck
0	In-Band-Bereitstellung: Stellen Sie dem Peer ein gemeinsames Geheimnis zur Verfügung, das in der sicheren Phase 1 verwendet werden kann.	Verwendet das Authenticated Diffie-Hellman-Protokoll (ADHP). Diese Phase ist unabhängig von anderen Phasen; Daher kann in der Zukunft jedes andere Schema (Inband oder Out-of-Band) verwendet werden.	Die Anforderung an den Client entfällt, jedes Mal, wenn ein Client einen Netzwerkzugriff erfordert, ein Master-Secret festzulegen
1	Tunneleinrichtung	Authentifizierung unter Verwendung des PAC und Einrichtung eines Tunnelschlüssels	Schlüsseleinrichtung, um Vertraulichkeit und Integrität während des Authentifizierungsprozesses in Phase 2 bereitzustellen
2	Authentifizierung	Authentifizierung des Peers	Mehrere getunnelte, sichere Authentifizierungsmechanismen (ausgetauschte Anmeldeinformationen)

Wenn die automatische PAC-Bereitstellung aktiviert ist, weist EAP-FAST eine leichte Sicherheitsanfälligkeit auf, bei der ein Angreifer die PAC abfangen und diese verwenden kann, um die Anmeldeinformationen der Benutzer zu beeinträchtigen. Diese Sicherheitsanfälligkeit wird durch manuelle PAC-Bereitstellung oder durch Verwendung von Serverzertifikaten für die PAC-Bereitstellungsphase verringert.

Es ist erwähnenswert, dass die PAC-Datei auf Benutzerbasis ausgegeben wird. Dies ist eine Anforderung in RFC 4851, Abschnitt 7.4.4. Wenn sich also ein neuer Benutzer von einem Gerät aus im Netzwerk anmeldet, muss zuerst eine neue PAC-Datei bereitgestellt werden. Dies ist ein Grund, warum es schwierig ist, EAP-FAST nicht im unsicheren anonymen Bereitstellungsmodus auszuführen. Die Alternative ist, stattdessen Gerätekennwörter zu verwenden, das Gerät wird jedoch im Netzwerk und nicht im Benutzer überprüft.

EAP-FAST kann ohne PAC-Dateien verwendet werden und fällt auf normale TLS zurück.

EAP-FAST wird in Apple OS X 10.4.8 und neuer nativ unterstützt. Cisco bietet ein EAP-FAST-Modul ^[25] für Windows Vista ^[26] und spätere Betriebssysteme an, das eine erweiterbare EAPHost-Architektur für neue Authentifizierungsmethoden und Supplicants aufweist. ^[27]

EAP-Abonnentenkennungsmodul (EAP-SIM) edit ]

Das EAP Subscriber Identity Module (EAP-SIM) wird für die Authentifizierung und die Verteilung des Sitzungsschlüssels verwendet, indem das Subscriber Identity Module (SIM) aus dem Global System for Mobile Communications (GSM) verwendet wird.

GSM-Mobilfunknetze verwenden eine Teilnehmeridentitätsmodulkarte, um die Benutzerauthentifizierung durchzuführen. EAP-SIM verwendet einen SIM-Authentifizierungsalgorithmus zwischen dem Client und einem Authentifizierungs-, Autorisierungs- und Kontoführungsserver (AAA-Server), der die gegenseitige Authentifizierung zwischen Client und Netzwerk ermöglicht.

In EAP-SIM ersetzt die Kommunikation zwischen der SIM-Karte und dem Authentication Center (AuC) die Notwendigkeit eines vordefinierten Kennworts zwischen dem Client und dem AAA-Server.

Die A3 / A8-Algorithmen werden einige Male mit unterschiedlichen 128-Bit-Herausforderungen ausgeführt. Es werden also mehr 64-Bit-Kc-s verwendet, die zu stärkeren Schlüsseln kombiniert / gemischt werden (Kc-s werden nicht verwendet.) direkt). Das Fehlen gegenseitiger Authentifizierung bei GSM wurde ebenfalls überwunden.

EAP-SIM wird in RFC 4186 beschrieben.

EAP-Authentifizierungs- und Schlüsselvereinbarung (EAP-AKA) [ edit ]

Extensible Authentication-Protokollmethode für die Authentifizierung und Schlüsselvereinbarung mit einem UMTS (Universal Mobile Telecommunications System) (EAP-AKA), ist ein EAP-Mechanismus für die Authentifizierung und Verteilung von Sitzungsschlüsseln mithilfe des UMTS Subscriber Identity Module (USIM). EAP-AKA ist in RFC 4187 definiert.

EAP-Authentifizierung und Schlüsselvereinbarung prime (EAP-AKA ') [ edit ]

Die EAP-AKA-Variante von EAP-AKA, die in RFC 5448 definiert ist und für verwendet wird Nicht-3GPP-Zugriff auf ein 3GPP-Kernnetzwerk. Zum Beispiel über EVDO, WiFi oder WiMax.

EAP-generische Token-Karte (EAP-GTC) [ edit ]

Die EAP-generische Token-Karte oder EAP-GTC ist eine von Cisco als Alternative zu PEAPv0 entwickelte EAP-Methode. EAP-MSCHAPv2 und definiert in RFC 2284 und RFC 3748. EAP-GTC enthält eine Textabfrage vom Authentifizierungsserver und eine Antwort, die von einem Sicherheitstoken generiert wird. Der Authentifizierungsmechanismus von PEAP-GTC ermöglicht die generische Authentifizierung bei einer Reihe von Datenbanken wie NDS (Novell Directory Service) und LDAP (Lightweight Directory Access Protocol) sowie die Verwendung eines Einmalpassworts.

EAP-verschlüsselter Schlüsselaustausch (EAP-EKE) [ edit ]

EAP mit dem verschlüsselten Schlüsselaustausch (EAP-EKE) ist eine der wenigen EAP-Methoden, die sichere gegenseitige Sicherheit bieten Authentifizierung mit kurzen Passwörtern und ohne Public-Key-Zertifikate. Es ist ein Drei-Runden-Austausch, der auf der Diffie-Hellman-Variante des bekannten EKE-Protokolls basiert.

EAP-EKE ist in RFC 6124 angegeben.

Encapsulation [ edit ]

EAP ist kein Drahtprotokoll; Stattdessen werden nur Nachrichtenformate definiert. Jedes Protokoll, das EAP verwendet, definiert eine Methode zum Einkapseln von EAP-Nachrichten in den Nachrichten dieses Protokolls.

IEEE 802.1X [ edit ]

Die Einkapselung von EAP über IEEE 802 ist in IEEE 802.1X definiert und als "EAP over LANs" oder EAPOL bekannt. ^[28][29][30] EAPOL Ursprünglich für IEEE 802.3-Ethernet in 802.1X-2001 entwickelt, wurde es jedoch für andere IEEE 802-LAN-Technologien wie IEEE 802.11 Wireless und Fiber Distributed Data Interface (ISO 9314-2) in 802.1X-2004 präzisiert. ^[31] Das EAPOL-Protokoll wurde ebenfalls für die Verwendung mit IEEE 802.1AE (MACsec) und IEEE 802.1AR (Initial Device Identity, IDevID) in 802.1X-2010 modifiziert. ^[32]

Wenn EAP von einem aktivierten 802.1X aufgerufen wird NAS-Geräte (Network Access Server), z. B. ein IEEE 802.11i-2004 Wireless Access Point (WAP), können moderne EAP-Verfahren einen sicheren Authentifizierungsmechanismus bereitstellen und einen sicheren privaten Schlüssel (Pair-wise Master Key, PMK) zwischen dem Client und aushandeln NAS, der dann für eine drahtlose Verschlüsselungssitzung verwendet werden kann, wobei TKIP- oder CCMP-Verschlüsselung (basierend auf AES) verwendet wird.

PEAP [ edit ]

Das Protected Extensible Authentication-Protokoll, auch Protected EAP oder einfach PEAP genannt, ist ein Protokoll, das EAP in einer möglicherweise verschlüsselten und authentifizierten Transport Layer Security einkapselt. TLS) -Tunnel. ^[33][34][35] Ziel war es, Mängel im EAP zu beheben. EAP ging von einem geschützten Kommunikationskanal aus, der beispielsweise durch die physische Sicherheit bereitgestellt wird, so dass keine Einrichtungen zum Schutz der EAP-Konversation bereitgestellt wurden. ^[36]

PEAP wurde gemeinsam von Cisco Systems, Microsoft und entwickelt RSA-Sicherheit. PEAPv0 war die in Microsoft Windows XP enthaltene Version und wurde nominell in draft-kamath-pppext-peapv0-00 definiert. PEAPv1 und PEAPv2 wurden in verschiedenen Versionen von draft-josefsson-pppext-eap-tls-eap definiert. PEAPv1 wurde in draft-josefsson-pppext-eap-tls-eap-00 durch draft-josefsson-pppext-eap-tls-eap-05 definiert, ^[37] und PEAPv2 wurde in Versionen definiert, die mit draft-josefsson-pppext-eap beginnen -tls-eap-06. ^[38]

Das Protokoll gibt nur die Verkettung mehrerer EAP-Mechanismen an und keine bestimmte Methode. ^[34][39] Die Verwendung der Methoden EAP-MSCHAPv2 und EAP-GTC ist am meisten allgemein unterstützt. ^{Zitat benötigt ]}

RADIUS und Durchmesser [ edit

Sowohl das RADIUS- als auch das Durchmesser-AAA-Protokoll können EAP-Nachrichten einkapseln. Sie werden häufig von NAS-Geräten (Network Access Server) verwendet, um EAP-Pakete zwischen IEEE 802.1X-Endpunkten und AAA-Servern weiterzuleiten, um IEEE 802.1X zu ermöglichen.

PANA [ edit ]

Das Protokoll zur Durchführung der Authentifizierung für den Netzwerkzugriff (PANA) ist ein IP-basiertes Protokoll, mit dem sich ein Gerät bei einem Netzwerk authentifizieren kann . PANA definiert keine neuen Authentifizierungsprotokolle, Schlüsselverteilungen, Schlüsselvereinbarungen oder Schlüsselableitungsprotokolle. Für diese Zwecke wird EAP verwendet, und PANA trägt die EAP-Nutzlast. PANA ermöglicht die Auswahl dynamischer Dienstanbieter, unterstützt verschiedene Authentifizierungsmethoden, eignet sich für Roaming-Benutzer und ist unabhängig von den Mechanismen der Verbindungsschicht.

PPP [ edit ]

EAP war ursprünglich eine Authentifizierungserweiterung für das Point-to-Point-Protokoll (PPP). PPP unterstützt EAP seit der Einführung von EAP als Alternative zu CHAP (Challenge-Handshake Authentication Protocol) und PAP (Password Authentication Protocol), die schließlich in EAP integriert wurden. Die EAP-Erweiterung für PPP wurde zuerst in RFC 2284 definiert und ist nun durch RFC 3748 überholt.

Siehe auch [ edit ]

Referenzen [ ]

1. ^ ^{a b} RFC 3748, § 1
2. ^ EAP-NOOB-Modell auf GitHub
3. George Ou (11. Januar 2007). "Ultimativer Wireless-Sicherheitsleitfaden: Eine Einführung in die LEAP-Authentifizierung". TechRepublic . 2008-02-17 .
4. ^ Dan Jones (1. Oktober 2003). "Schauen Sie vor dem Sprung". Unstrung . Nach dem Original am 9. Februar 2008 archiviert . Abgerufen 2008-02-17 .
5. ^ "Verstehen der aktualisierten WPA- und WPA2-Standards". techrepublic.com . Abgerufen 2008-02-17 .
6. ^ ^{a b} Byrd, Christopher (5. Mai 2010). "Open Secure Wireless" (PDF) . Archiviert aus dem Original (PDF) am 12. Dezember 2013 . 2013-08-14 .
7. ^ ^{a b} RFC 5216: Die EAP-TLS Authentifizierungsprotokoll Internet Engineering Task Force, März 2008, Die certificate_request-Nachricht ist enthalten, wenn der Server den Peer dazu auffordert, sich über einen öffentlichen Schlüssel zu authentifizieren. Während der EAP-Server eine Peer-Authentifizierung erfordern sollte, ist dies nicht zwingend erforderlich, da unter bestimmten Umständen keine Peer-Authentifizierung erforderlich ist (z. B. Notfalldienste, wie in [UNAUTH] beschrieben) oder wenn sich der Peer auf andere Weise authentifiziert
8. ^ "Hinzufügen eines UNAUTH-TLS-Anbieterspezifischen EAP-Typs". hostapd . Archiviert aus dem Original am 2013-02-13 . Abgerufen 2013-08-14 .
9. ^ "HS 2.0R2: Hinzufügen der nur für WFA-Server vorgesehenen EAP-TLS-Peer-Methode". hostapd . Archiviert aus dem Original am 30.09.2014 . Abgerufen 2014-05-06 .
10. ^ "HS 2.0R2: WAP-Server hinzufügen - Nur EAP-TLS-Servermethode". hostapd . Archiviert aus dem Original am 30.09.2014 . Abgerufen 2014-05-06 .
11. ^ Byrd, Christopher (1. November 2011). "Open Secure Wireless 2.0". Nach dem Original am 26. November 2013 archiviert . 2013-08-14 .
12. ^ Rand Morimoto; Kenton Gardinier; Michael Noel; Joe Coca (2003). Microsoft Exchange Server 2003 Unleashed . Sams. p. 244. ISBN 978-0-672-32581-6.
13. ^ "Alternative Verschlüsselungsschemata: Die Schwachstellen in statischer WEP ansprechen". Ars Technica . 2008-02-17 .
14. ^ "922574", Knowledge Base Microsoft
15. "EAP- POTP-Authentifizierungsprotokoll ". Juniper.net . Abgerufen 2014-04-17 .
16. ^ FreeRADIUS EAP-Modul rlm_eap_pwd
17. ^ Unterstützung für EAP-PWD gemäß RFC 5931
18. ^ hinzugefügt mit nur einem Kennwort
19. ^ EAP-TTLS unter Windows 8 (Build 8250)
20. ^ "802.1x / EAP-TTLS-Unterstützung? - Windows Phone Central-Foren". Forums.wpcentral.com . Abgerufen 2014-04-17 .
21. ^ "Enterprise Wi-Fi authentication (EAP)". Microsoft.com . Abgerufen 2014-04-23 .
22. ^ TTLSv1-Internetentwurf
23. ^ "Ultimative Sicherheitsrichtlinie für drahtlose Netzwerke: Eine Einführung in die Cisco EAP-FAST-Authentifizierung". techrepublic.com . 2008-02-17 .
24. ^ "EAP-FAST> EAP-Authentifizierungsprotokolle für WLANs". Ciscopress.com . Abgerufen 2014-04-17 .
25. ^ [1] Archiviert am 10. Februar 2009 bei der Wayback Machine
26. ^ Wie installiere ich CISCO EAP-FAST auf meinem Computer? Computer?
27. ^ EAPHost in Windows
28. ^ RFC 3748, § 3.3
29. ^ RFC 3748, § 7.12
30. IEEE 802.1X-2001, § 7
31. ^ IEEE 802.1X-2004, § 3.2.2
32. ^ IEEE 802.1X-2010, § 5
33. ^ Microsofts PEAP-Version 0, Draft-Kamath-pppext -peapv0-00, §1.1
34. ^ a