Diskussion:IEEE 802.1X
evtl nach IEEE 802.1x verschieben? von Artikel hierher verschoben. --Habakuk <>< 10:04, 2. Feb 2005 (CET)
Gute Idee. Der Standard heißt ja "IEEE 802.1x" und nicht "802.1x". 802.1x wurde nach IEEE_802.1x verschoben. Ich werde jetzt den Artikel noch auf die korrekte Bezeichnung hin anpassen. Endorphine 18:58, 13. Mai 2005 (CEST)
In der Textstelle "oder einem logischen im IEEE 802.11 VLAN" ist wohl "WLAN" statt "VLAN" gemeint. Ich schlage vor, die zu korrigieren.
Sorry, ich hätte eine Frage: welche Vorteile ergeben sich aus der Tatsache, dass die Authentisierungsprüfung verteilt durch Authenticator und den Authentication Server realisiert wird ?
Was noch im Artikel anzumerken wäre, ist die innere EAP Authentisierung. Hier kann ja PAP, PEAP MD5-Challenge, EAP-MSCHAP v2 oder Smartcard verwendet werden. Zu Bemerken ist auch, das nicht jedes Betriebssystem ohne Zusatzsoftware bereits jedes verfahren kann.
Hallo
Die authentication geschieht nur zwischen einem client und dem switch an den er angeschloßen ist. dieses geschieht über das protokoll eapol. die abfrage wird an einen radiusserver weitergegeben, dieses geschied aber auf einem anderen protokoll (radius). das sehen viele hersteller z.b. cisco aber nicht mehr als eee802.1x an. da es auch andere möglichkeiten geben wirde z.b. tacats+ und andere
mehr über dieses thema bei http://www.cisco.com
---
Hallo Unbekannter,
wenn man es genauer wissen will, wird ein IEEE 802.3 frame genommen. In die Payload des IEEE 802.3 Frames kommt EAPOL Frame. In die Payload des EAPOL Frames kommt das EAP Frame. In die Payload des EAP Frames die Daten der EAP Methode. Weil der Supplicant die MAC Adresse vom Authenticator nicht kennt, setzt er ins DST Feld des IEEE 802.3 Felds die MAC-Adresse 01:80:c2:00:00:03 ein. Die ist dafür reserviert. Falls es jedoch ein drahtloser Authenticator ist, also ein WLAN Access Point, wird die MAC Adrese des APs genommen, die aus der Sitzungsverbindung zum AP bekannt ist. Der Authenticator bekommt das Paket: "IEEE 802.3 + EAPOL + EAP + EAP-Methode", extrahiert den Teil ab EAP und verpackt es in die Payload eines RADIUS oder TACACS oder DIAMETER Protokolls. Der Authenticator frickelt die Daten aus der Payload in dem EAP-Methodenpaket auseinander um festzustellen: hey Credential, gehashed mit MD5 oder ein Zertifikat, was sagt mein Backend dazu? Ah! ich kenne es, also los eine RADIUS Access-Accept Nachricht an den Authenticator senden um den Authenticator reinzulassen. Moment da müssen noch 2, 3 Attribute in die Access Accept Antwort, in welches VLAN er z.B. soll (s. http://freeradius.org/rfc/attributes.html mit Verweisen auf die jeweiligen RFCs).
Wenn EAP nicht bis zum AS gelangt, was ich aus deiner Bemerkung heraus interpretiere, warum muss man die erlaubten EAP Methoden am AS konfigurieren? EAP wird zwischen dem Authenticator und dem AS nur in einem anderem Protokoll getunnelt, ob es RADIUS, TACACS+ oder XYZ heißt.
S. RFC http://www.ietf.org/rfc/rfc3579.txt; RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP); 2.1. Protocol Overview.
--
Frage: Ist das unter Windows benutzte AEGIS Protocol (IEEE 802.1x) mit dem hier verhandelten X identisch? Wenn ja, sollte AEGIS erwähnt werden – wenn nein, eigentlich auch (zur Unterscheidung).woi 12:11, 31. Jan. 2012 (CET)
Verschoben Bearbeiten
Ich habe die Seite eben nach IEEE 802.1X verschoben, weil der Standard so heißt (mit großen X). Kleinigkeit, aber korrekt... --Vertigo-1 09:25, 28. Sep. 2007 (CEST)
Lesbarkeit Bearbeiten
[...] In der Praxis wird einer LDAP Anbindung oft der Vorzug gegeben. Der Vorteil liegt auf der Hand: Bestehende Domänenbenutzerkennungen sind im Active Directory Service (ADS) von Microsoft Betriebssystemen bereits vorhanden. [...]
Wieso ist plötzlich von ActiveDirectory die Rede?? Generell ist der ganze Absatz mit recht vielen Buzzwords versehen, ohne Verlinkungen und teilweise auch ohne, dass es notwendig wäre. Vielleicht mal Grundüberarbeiten? (nicht signierter Beitrag von 129.70.136.205 (Diskussion | Beiträge) 18:17, 31. Okt. 2009 (CET))
Hallo miteinander!
Ich hätte mal ne ganz andere Frage. Und zwar habe ich gelernt, dass 802.1X ein portbasiertes Authentifikationsverfahren sei. Bei einem Switch etwa "meldet" sich der Teilnehmer des Ports
beim Network Access Server(NAS), also dem Switch, an. Dieser gibt dann den Port frei oder eben nicht. Wie sieht es jedoch mit WLANs aus? Der NAS kann hier ja nicht irgendwelche Ports freischalten.
Und nach einer erfolgreichen Authentifikation das gesamte WLAN freizugeben wäre auch nicht sinn der Sache. Und eine PPP-Verbindung soll auch nicht aufgebaut werden. Oder doch???
Gruß Jimmy (nicht signierter Beitrag von 91.49.233.52 (Diskussion | Beiträge) 13:13, 16. Jan. 2010 (CET))
Sortierung unter Abschnitt: Betriebssysteme mit IEEE 802.1X Unterstützung Bearbeiten
Sollten die aufgezählten Betriebssysteme nicht alphabetisch sortiert sein? (nicht signierter Beitrag von 82.83.193.95 (Diskussion) 22:53, 21. Mai 2011 (CEST))
Defekte Weblinks Bearbeiten
| Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt. |
|---|
|
- http://standards.ieee.org/board/rev/110early.html
- Vielleicht ist eine archivierte Version geeignet: archive.org
- Im Jahr 2012 bereits defekt gewesen.
Quellen und somit Teile des Artikels sind veraltet Bearbeiten
da diese alleine auf IEEE 802.1X-2004 basieren. Es gibt aber eine Revision in 2010, die nicht gelistet ist in den Quellen sondern nur als Referenzen. Das langt nicht, z.B. ist die Nennung "siehe Kapitel 5.1" bezogen auf Revision 2004, in der aktuellen Revision steht da aber was ganz anderes! Alleine unter Sicherheitsprobleme wird im Text Revision 2010 erwähnt, aber als "kürzlich verabschiedete", was nun ja vor sechs Jahren war. (nicht signierter Beitrag von Hhhenning (Diskussion | Beiträge) 21:35, 22. Sep. 2016 (CEST))