12
Funktionsweise 802.1X Authentifizierung
Hallo,
bin gerade am erarbeiten der Funktionsweise einer 802.1X Authentifizierung.
Da allerdings meine Englisch Kenntnisse nicht gerade die besten sind, sind die Englischen Artikel die im Netz zu finden sind sehr schwer bis gar nicht für mich zu verstehen.
Das was ich bis jetzt verstanden habe, bin ich zu folgender Erkenntniss gekommen:
Supplicant (WLAN-Client) <--> Authenticator (AP) <--> Authentication Server (RADIUS)
1. Der Supplicant kommuniziert mit dem Authenticator über das Protokoll EAPoW* in dem die EAP-Pakete eingekapselt werden.
2. Anschließend kommuniziert der Authenticator mit dem Authentication Server über das Protokoll RADIUS in dem die EAP-Pakete (Anfragen) vom Supplicant eingekapselt sind.
3. Der RADIUS-Server prüft die Anfrage (Benutzername/Passwort) und teilt dem Supplicant das Ergebnis mit.
4. Daraufhin gewährt bzw. verweigert der Authenticator dem Supplicant den Zugang zum Netzwerk.
Stimmt das soweit??
EAPoW* = Man liest häufig von EAPoL, würde das in meiner Konstellation auch so heißen, oder nur wenn Switches o.ä. eingesetzt werden? Bei mir wäre es ja ein Access-Point...
bin gerade am erarbeiten der Funktionsweise einer 802.1X Authentifizierung.
Da allerdings meine Englisch Kenntnisse nicht gerade die besten sind, sind die Englischen Artikel die im Netz zu finden sind sehr schwer bis gar nicht für mich zu verstehen.
Das was ich bis jetzt verstanden habe, bin ich zu folgender Erkenntniss gekommen:
Supplicant (WLAN-Client) <--> Authenticator (AP) <--> Authentication Server (RADIUS)
1. Der Supplicant kommuniziert mit dem Authenticator über das Protokoll EAPoW* in dem die EAP-Pakete eingekapselt werden.
2. Anschließend kommuniziert der Authenticator mit dem Authentication Server über das Protokoll RADIUS in dem die EAP-Pakete (Anfragen) vom Supplicant eingekapselt sind.
3. Der RADIUS-Server prüft die Anfrage (Benutzername/Passwort) und teilt dem Supplicant das Ergebnis mit.
4. Daraufhin gewährt bzw. verweigert der Authenticator dem Supplicant den Zugang zum Netzwerk.
Stimmt das soweit??
EAPoW* = Man liest häufig von EAPoL, würde das in meiner Konstellation auch so heißen, oder nur wenn Switches o.ä. eingesetzt werden? Bei mir wäre es ja ein Access-Point...
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 208053
Url: https://administrator.de/contentid/208053
Printed on: April 18, 2024 at 08:04 o'clock
12 Comments
Latest comment
Hallo,
das ist soweit richtig, EAPoW steht für EAP over Wlan und das ist in deinem Fall das richtige encapsulation weil du ein Access Point als Authenticator hast. Ist der Authenticator z.B. ein Switch, der 802.1X Authentifizierung machen kann, dann verbindet man Supplicant und Authenticator über ein LAN-Kabel und man spricht von EAPoL (EAP over LAN).
http://www.heise.de/netze/artikel/WLAN-und-LAN-sichern-mit-IEEE-802-1X- ...
http://www.tecchannel.de/netzwerk/wlan/2023084/ieee_802_1x_zugriffskont ...
Gruß
m
das ist soweit richtig, EAPoW steht für EAP over Wlan und das ist in deinem Fall das richtige encapsulation weil du ein Access Point als Authenticator hast. Ist der Authenticator z.B. ein Switch, der 802.1X Authentifizierung machen kann, dann verbindet man Supplicant und Authenticator über ein LAN-Kabel und man spricht von EAPoL (EAP over LAN).
http://www.heise.de/netze/artikel/WLAN-und-LAN-sichern-mit-IEEE-802-1X- ...
http://www.tecchannel.de/netzwerk/wlan/2023084/ieee_802_1x_zugriffskont ...
Gruß
m
1
Hier findest du auch noch ein paar Grundlageninfos zu dem Thema:
Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch
und
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch
und
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
1Zitat von @matthew77:
Hallo,
das ist soweit richtig, EAPoW steht für EAP over Wlan und das ist in deinem Fall das richtige encapsulation weil du ein
Access Point als Authenticator hast. Ist der Authenticator z.B. ein Switch, der 802.1X Authentifizierung machen kann, dann
verbindet man Supplicant und Authenticator über ein LAN-Kabel und man spricht von EAPoL (EAP over LAN).
http://www.heise.de/netze/artikel/WLAN-und-LAN-sichern-mit-IEEE-802-1X- ...
http://www.tecchannel.de/netzwerk/wlan/2023084/ieee_802_1x_zugriffskont ...
Gruß
m
Hallo,
das ist soweit richtig, EAPoW steht für EAP over Wlan und das ist in deinem Fall das richtige encapsulation weil du ein
Access Point als Authenticator hast. Ist der Authenticator z.B. ein Switch, der 802.1X Authentifizierung machen kann, dann
verbindet man Supplicant und Authenticator über ein LAN-Kabel und man spricht von EAPoL (EAP over LAN).
http://www.heise.de/netze/artikel/WLAN-und-LAN-sichern-mit-IEEE-802-1X- ...
http://www.tecchannel.de/netzwerk/wlan/2023084/ieee_802_1x_zugriffskont ...
Gruß
m
Super, danke!
Mal angenommen, es würde das Verfahren PEAP/MS-CHAPv2 eingesetzt werden.
Wie würde das dann ablaufen und welches Protokoll steckt dann in welchem drin?
Versteh auch nicht ganz, wie dann die Verschlüsselung (WPA2/AES) zwischen Access-Point und WLAN-Client aufgebaut wird. Oder ist für die Verschlüsselung das ganze Verfahren PEAP/MS-CHAPv2 notwendig?
Irgendwie verwirrt mich das ganze...
Über eine Hilfe würde ich mich echt sehr freuen!
Gruß
Also, PEAP ist eine EAP-Methode (es gibt noch EAP-TLS, EAP-TTLS), bei der eine SSL/TLS-Tunnel zwischen Client und Radiusserver aufgebaut wird, das nennt man die äussere Verschlüsselung oder der äussere Tunnel, innerhalb dieses sicheren Tunnels wird dann eine weitere EAP Verbindung (der innere Tunnel) mit den möglichen EAP Authentisierungstypen aufgebaut, wobei zur Zeit nur MSCHAPv2 zur Verfügung steht, wenn PEAP als EAP-Methode eingesetzt wird.
Für den Schlüsselaustausch zwischen Wlan-Client und AP wird ein MasterKey ausgehandelt, mit dem ein symmetrischer Schlüssel dynamisch generiert und ausgetauscht wird und die Kommunikation zwischen den beiden verschlüsselt.
http://wlan.uni-regensburg.de/wlan8021x.py
http://www.qucosa.de/fileadmin/data/qucosa/documents/5153/data/WLAN.pdf
Gruß
m
Für den Schlüsselaustausch zwischen Wlan-Client und AP wird ein MasterKey ausgehandelt, mit dem ein symmetrischer Schlüssel dynamisch generiert und ausgetauscht wird und die Kommunikation zwischen den beiden verschlüsselt.
http://wlan.uni-regensburg.de/wlan8021x.py
http://www.qucosa.de/fileadmin/data/qucosa/documents/5153/data/WLAN.pdf
Gruß
m
1Zitat von @matthew77:
Also, PEAP ist eine EAP-Methode (es gibt noch EAP-TLS, EAP-TTLS), bei der eine SSL/TLS-Tunnel zwischen Client und Radiusserver
aufgebaut wird, das nennt man die äussere Verschlüsselung oder der äussere Tunnel, innerhalb dieses sicheren
Tunnels wird dann eine weitere EAP Verbindung (der innere Tunnel) mit den möglichen EAP Authentisierungstypen aufgebaut,
wobei zur Zeit nur MSCHAPv2 zur Verfügung steht, wenn PEAP als EAP-Methode eingesetzt wird.
Also, PEAP ist eine EAP-Methode (es gibt noch EAP-TLS, EAP-TTLS), bei der eine SSL/TLS-Tunnel zwischen Client und Radiusserver
aufgebaut wird, das nennt man die äussere Verschlüsselung oder der äussere Tunnel, innerhalb dieses sicheren
Tunnels wird dann eine weitere EAP Verbindung (der innere Tunnel) mit den möglichen EAP Authentisierungstypen aufgebaut,
wobei zur Zeit nur MSCHAPv2 zur Verfügung steht, wenn PEAP als EAP-Methode eingesetzt wird.
Würde das dann also bedeuten, dass das Protokoll "PEAP" dafür verwendet wird, um den SSL/TLS-Tunnel zwischen Client und RADIUS-Server aufzubauen und das Protokoll "MS-CHAPv2" hingegen beschreibt wie sich der Benutzer authentifizieren soll. In dem Fall mit Benutzername/Passwort. Wäre dies so richtig?
Wenn ja, der Client kommuniziert ja nur mit dem Access-Point direkt nicht aber mit dem RADIUS-Server. Daher packt der Access-Point die Pakete die via EAPoW vom Client kommen in das Protokoll RADIUS um und schickt sie an den RADIUS-Server. Da ja aber ein SSL/TLS-Tunnel zwischen Client und RADIUS-Server besteht kann ja der Access-Point nie in die Pakete reinschauen? Oder besteht zu dieser Zeit der SSL/TLS-Tunnel zwischen Client und RADIUS-Server noch gar nicht?
Gruß
Ja, EAP-PEAP gehört zu den hybrid-authentication-method, d.h. eine 2 stufige Authentifizierung.
Zuerst wird ein TLS-Kanal aufgebaut und innerhalb dieses Kanals erfolgt die Authentifizierung mittels MSCHAPv2.
Der AP muss auch nicht in die Pakete reinschauen, EAPoW ist auf Layer 2 und beinhaltet unter anderem die PEAP und TLS Daten, die EAPoW Pakete werden wiederum in ein WLAN 802.11 oder Ethernet 802.3-Frame eingebettet, vereinfacht sieht das so aus:
PEAP
EAPoW
WLAN / Ethernet
Gruß
m
Zuerst wird ein TLS-Kanal aufgebaut und innerhalb dieses Kanals erfolgt die Authentifizierung mittels MSCHAPv2.
Der AP muss auch nicht in die Pakete reinschauen, EAPoW ist auf Layer 2 und beinhaltet unter anderem die PEAP und TLS Daten, die EAPoW Pakete werden wiederum in ein WLAN 802.11 oder Ethernet 802.3-Frame eingebettet, vereinfacht sieht das so aus:
PEAP
EAPoW
WLAN / Ethernet
Gruß
m
1
So in etwa sieht das Paket aus .
{ WLAN oder Ethernet [ EAPoW oder EAPoL ( EAP < TLS > ) ] }
{ WLAN oder Ethernet [ EAPoW oder EAPoL ( EAP < TLS > ) ] }
Zitat von @matthew77:
So in etwa sieht das Paket aus .
{ WLAN oder Ethernet [ EAPoW oder EAPoL ( EAP < TLS > ) ] }
So in etwa sieht das Paket aus .
{ WLAN oder Ethernet [ EAPoW oder EAPoL ( EAP < TLS > ) ] }
Vielen Dank, deine Antworten sind echt Top!
Was mir gerade noch eingefallen ist, wird dann der SSL/TLS-Tunnel von PEAP nur solange verwendet, bis der Benutzer authentifiziert ist und der Access-Point weiß, ob er den Port freigeben bzw. verweigern soll?
Wenn diese Information der Access-Point erhalten hat, läuft dann die Verbindung nur noch AES verschlüsselt (bei WPA2) über den Access-Point?
Gruß
PS: Hab jetzt schon öfters gelsen, dass wenn der EAP-Typ "PEAP" gemeint ist, dann schreiben viele von "EAP-PEAP" ... aber wäre dies nicht falsch, müsste es nicht einfach nur "PEAP" heißen, da ja "EAP" schon bei "PEAP" mitdrin steckt?
Du musst aufpassen das du hier nicht Äpfel mit Birnen vergleichst !
Die reine WLAN Verschlüsselung hat nichts mit der Benutzer Authentisierung zu tun ! Das sind 2 paar Schuhe.
Das eine handelt der AP mit dem Client direkt aus, das andere klärt der AP mit dem Radius Server ob dieser User ins Netzwerk darf oder nicht.
2 getrennte Prozesse also.
Die reine WLAN Verschlüsselung hat nichts mit der Benutzer Authentisierung zu tun ! Das sind 2 paar Schuhe.
Das eine handelt der AP mit dem Client direkt aus, das andere klärt der AP mit dem Radius Server ob dieser User ins Netzwerk darf oder nicht.
2 getrennte Prozesse also.
1Zitat von @aqui:
Du musst aufpassen das du hier nicht Äpfel mit Birnen vergleichst !
Die reine WLAN Verschlüsselung hat nichts mit der Benutzer Authentisierung zu tun ! Das sind 2 paar Schuhe.
Das eine handelt der AP mit dem Client direkt aus, das andere klärt der AP mit dem Radius Server ob dieser User ins Netzwerk
darf oder nicht.
2 getrennte Prozesse also.
Du musst aufpassen das du hier nicht Äpfel mit Birnen vergleichst !
Die reine WLAN Verschlüsselung hat nichts mit der Benutzer Authentisierung zu tun ! Das sind 2 paar Schuhe.
Das eine handelt der AP mit dem Client direkt aus, das andere klärt der AP mit dem Radius Server ob dieser User ins Netzwerk
darf oder nicht.
2 getrennte Prozesse also.
Okay, wird dann die Verschlüsselung vom AP zwischen Client und AP ERST aufgebaut, nachdem die Authentifizierung über den RADIUS-Server abgeschlossen ist?
Jein... In der Phase 1 identifiziert der Client die Security Policy des APs über dessen Beacon oder nachdem er einen Probe Request gesendet hat mit der Probe Response des APs.
Daraufhin sendet der Client einen Association Request an den AP und der antwortet mit einem Association Response. All das ist noch Standard Open Authentication.
Je nach Security Policy Information Field sendet der AP ein "Request Identity" an den Client (Supplicant) was der AP (Authenticator) dann an den Radius forwardet. Nach dessen Antwort wird dann ein Master Key generiert und der Radius schickt ein "Accept".
Daraus wird dann in einem 4 Way Handshaking der Session Key berechnet und die Verbindung verschlüsselt.
Es greift zwar etwas ineinander die Prozesse sind aber dennoch getrennt zu betrachten.
Nimm dir mal einen Wireshark Sniffer und sniffer das mal mit auf dem WLAN Interface, dort sieht man es dann recht detailiert !
Daraufhin sendet der Client einen Association Request an den AP und der antwortet mit einem Association Response. All das ist noch Standard Open Authentication.
Je nach Security Policy Information Field sendet der AP ein "Request Identity" an den Client (Supplicant) was der AP (Authenticator) dann an den Radius forwardet. Nach dessen Antwort wird dann ein Master Key generiert und der Radius schickt ein "Accept".
Daraus wird dann in einem 4 Way Handshaking der Session Key berechnet und die Verbindung verschlüsselt.
Es greift zwar etwas ineinander die Prozesse sind aber dennoch getrennt zu betrachten.
Nimm dir mal einen Wireshark Sniffer und sniffer das mal mit auf dem WLAN Interface, dort sieht man es dann recht detailiert !
1
Im prinzip ist das vergleichbar mit eine HTTPS-Verbindung, der Client und Server tauschen Zertifikate aus: Es wir ein SSL-Kanal aufgebaut (asymmetrische Verschlüsselung) dann wird in diesem Kanal der generierte symmetrische Schlüssel zwischen Client und Server ausgetauscht (symmetrische Verschlüsselung), mit dem der Rest der Kommunikation ver- und entschlüsselt wird.
Und bei PEAP baut WlanClient mit dem Master-Zertifikat (ca.crt) eine SSL Verbindung zum RadiusServer auf, damit 2 Dinge abhörsicher übertragen werden können, erstens die Authentifizierung eines Benutzers, da kommt MSCHAP ins Spiel und zweitens die Übertragung eines vom RadiusServer generierten Schlüssel, der sog. Master-Key. Der Master-Key wird also vom Server generiert und zum WlanClient transportiert.
Der WlanClient und der RadiusServer leiten nun vom Master-Key einen weiteren Schlüssel ab, der Pairwise Master Key (PMK).
Der RadiusServer schickt nun den Pairwise Master Key zum AccessPoint, Jetzt sind der WlanClient, AP und der RadiusServer im Besitz vom PMK-Schlüssel.
Danach wird aus dem PMK-Schlüssel in einem Vier-Wege-Handshake-Verfahren zwischen dem WlanClient und dem AP der Pairwise Transient Keys (PTK) für die Verschlüsselung der Kommunikation abgeleitet. Der PTK selbst besteht aber aus mehreren Teilschlüsseln, die letzendlich die Kommunikation zwischen WlanClient und AP verschlüsseln.
Das sind :
KCK
KEK
TK (verschlüsselt die Daten)
und GTK (um multicast/broadcast zu verschlüsseln)
Welche Rolle nun TKIP oder CCMP/AES dabei spielen, ist dass sie die Stärke des TK (Temporal Key) beeinflussen. Der TK wird alle paar Minuten erneuert.
Hier sind 2 gute Seiten dazu:
http://www.tldp.org/HOWTO/8021X-HOWTO/intro.html
http://www.itwissen.info/definition/lexikon/PTK-pairwise-transient-key. ...
Gruß
m
Und bei PEAP baut WlanClient mit dem Master-Zertifikat (ca.crt) eine SSL Verbindung zum RadiusServer auf, damit 2 Dinge abhörsicher übertragen werden können, erstens die Authentifizierung eines Benutzers, da kommt MSCHAP ins Spiel und zweitens die Übertragung eines vom RadiusServer generierten Schlüssel, der sog. Master-Key. Der Master-Key wird also vom Server generiert und zum WlanClient transportiert.
Der WlanClient und der RadiusServer leiten nun vom Master-Key einen weiteren Schlüssel ab, der Pairwise Master Key (PMK).
Der RadiusServer schickt nun den Pairwise Master Key zum AccessPoint, Jetzt sind der WlanClient, AP und der RadiusServer im Besitz vom PMK-Schlüssel.
Danach wird aus dem PMK-Schlüssel in einem Vier-Wege-Handshake-Verfahren zwischen dem WlanClient und dem AP der Pairwise Transient Keys (PTK) für die Verschlüsselung der Kommunikation abgeleitet. Der PTK selbst besteht aber aus mehreren Teilschlüsseln, die letzendlich die Kommunikation zwischen WlanClient und AP verschlüsseln.
Das sind :
KCK
KEK
TK (verschlüsselt die Daten)
und GTK (um multicast/broadcast zu verschlüsseln)
Welche Rolle nun TKIP oder CCMP/AES dabei spielen, ist dass sie die Stärke des TK (Temporal Key) beeinflussen. Der TK wird alle paar Minuten erneuert.
Hier sind 2 gute Seiten dazu:
http://www.tldp.org/HOWTO/8021X-HOWTO/intro.html
http://www.itwissen.info/definition/lexikon/PTK-pairwise-transient-key. ...
Gruß
m
