Port Authentication

Das ist ein Standard einer genereller Methode für die Authentifizierung und Authorisierung in IEEE-802 Netzwerken

Bei der Netzwerkzugang auf einem Port (LAN, WLAN, VLAN) im Netz erfolgt die Authentifizierung eines Users durch den Autenticator der mittels eines Authentifizierungsservers (RADIUS-SERVER) welche die Teilnehmer Authentifizierungs informationen prüft und den den Authentikator zugewiesenen Dienste erlaubt oder verweigert

Ein user greift auf einen Lan via einem Port zu. 

Der unkontollierter Port ist zugänglich damit der User seine Authentifiuierungs informationen an den Authentication Server kommunizieren kann. 

Der kontrollierte Port wird anhand der Authentifizierungs stand frei geschaltet und erlaubt dem User auf die Dienste hinter den Controlled Port zuzugreifen. 

EAPol wird verwendet für die kommunikation zwischen User und Authenticatir Sytem

Authenticator Syste und authentication Server kommunizieren via AAA Protocol

Authentication off/Port On

keine authentication notwendig

Authentication on/Port on with default policy

Authentication notwendig, parzielle kontrolle erlaubt kommunikation ohne authentifizierung duch den controlled port für dedizierte kommunikatioenn (Wake on Lan, DHCP Internet access Printing)

AUthentication on/Port off

Restrictive mode, Keine kommunikation möglich ohne authentication

wurde ursprünglich als PPP entwickelt (Point to point protocol)

Es nicht ein Protocol sondern ein framework welche bekannte authentication protokoll unterstützt

EAP kapselt nur nachrichten zwischen supplicant und einem authentication server

die authentifizierungs methode kann ziwschen den kommunikation parteien ausgehandelt werden

1. Der supplicant fängt mit der kommunikation mit derm authenticator an (Authenticator und supplicant im CONNECTING state)
2. Supplicant sendet eine EAPOL start frame an den Authenticator um den authenfizierungs prozess zu starten
3. Wenn der Authentication Server den EAPOL start erhält dann antwortet er mit einem identity request um den supplicants um seine Identität zu erhalten
4. Der supplicant senden den identity response mit seiner identität. Anschliessend tauscht der Authentication Server und Authenticator die nötigen Informationen aus. Der erste identity exchange erfolgt im klartext. Es sind auch implementierungen vorhanden welche die identität zu einem später zeitpunkt übertragen wird. 
5. Sobald der Supplicant einen EAP request erhält mit den Radius Acces challenge wird der status des Supplicant PAE auf Authenticating gesetzt. Der supplicant antwortet mit einem EAP response(credentials) message in welcher der Radius access request vorhanden ist
6. Je nach dem wird der user jetzt authentifiziert und der supplicant status wird auf Authenticated gewechselt oder beide stati wechseln auf HELD und der authentifizierungs vorgang isc fehgeschlagen

• EAP-MD5
  • Challenge Handshake authentication protocol 
  • generiert keine dynamische WEP keys
  • angreifbar mit dictionary attacks
  • angreofbar mit man in the middle weil keine gegenseitige authentifizierung vorgenommen wird
• EAP-LEAP
  • unterstützt dynamic WEP keys und gegenseitige authentifizierung
  • nicht mehr empfohlen von CISCO weil die user credentials nicht stark geschützt sind
• EAP-TLS
  • gegenseitige certifikat basiertes authentication 
  • das sicherste EAP standard
• EAP-TTLS
  • wie ein EAP-TLS aber nur der Server authentifiziert sich gegen den Client dann wird durch den getunelte verbindung der client authentifiziert mit seinen credentials
• PEAP
  • ähnlich wie EAP-TTLS (server cert und user credential via tls tunnel)
  • wird von Windows, OSX Linux, Android iOS unterstützt
  •