Child pages
  • 802.1X

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


IEEE 802.1X is a standard for authentication in computer networks.

The IEEE 802.1X standard provides a general method for authentication and authorization in IEEE 802.1X networks. At network access, a physical port on the LAN, a logical IEEE 802.1Q VLAN, or a WLAN, a subscriber is authenticated by the authenticator, which uses an authentication server (RADIUS server) to verify the authentication information provided by the subscriber (supplicant) and, if necessary, to allow or deny access to the services (LAN, VLAN, or WLAN) provided by the authenticator.

This possibility of using an authentication server makes network access possible even for locally unknown subscribers. For example, members of many universities can use WLAN at other universities via eduroam without having to set up guest access or the like open to everyone.

The standard recommends the Extensible Authentication Protocol (EAP) or the PPP-EAP-TLS Authentication Protocol for authentication, since no separate authentication protocols are defined.

According to IEEE, a capital letter must be used for the notation, since IEEE 802.1X is a stand-alone standard and does not supplement an existing standard.

  • Supplicants 
    are all IEEE 802.1X-authenticable devices (see IEEE 802.1X Article 5.1 "Requirements") that must authenticate to the network according to the network rule before the network device is allowed access to the network resources.
    In practice, the supplicant is implemented in the form of a software implementation. For example, Windows XP (including SP2) natively supports a supplement implementation. Furthermore you can also use the free supplicant implementations from the projects of Open1x or SecureW2 to build up an IEEE 802.1X infrastructure. However, not all network components (such as network printers) are able to authenticate to the network via IEEE 802.1X. Often old and even newer hardware lacks the IEEE 802.1X supplicant implementation. This is the biggest criticism of IEEE 802.1X when introducing IEEE 802.1X into production systems. Some switches provide the "MAC bypass" function for this problem, for example. This makes it possible to authenticate the network device using the MAC address. This allows authentication of devices that do not have an IEEE 802.1X supplicant implementation.

  • The authenticator 
    exists between the supplicant and the network to be protected. The role of the authenticator is to verify the authenticity of the supplicant, similar to the role of a doorman in an identity card check. If the supplicant can successfully identify himself to the authenticator with valid credentials, the supplicant is granted access to the network by the authenticator. If authentication fails, access is denied. In practice, the authenticator can be an IEEE 802.1X-enabled switch, router or IEEE 802.11 WLAN access point. The credentials are usually requested by the Authenticator from an Authentication Server (AS). The authentication server is found in the IEEE 802.1X model in a trusted network.

  • Port Access Entity: PAE 
    The PAE, which can be presented in practice as a port at the switch, implements a state machine by always mapping the respective authentication state between supplicant and authenticator at the controlled port. The IEEE 802.1X provides three possible access modes for supplicants for the access setting in the PAE:
    • ForceUnauthorized: The controlled port is in "not authorized" mode. This blocks any access by a supplicant. It does not matter whether the supplicant can authenticate successfully or not, access is always blocked.
    • ForceAuthorized: The opposite of ForceUnauthorized. The controlled port is in "authorized" mode. The supplicant is always granted access. It is not important whether the supplicant can authenticate to the authenticator, access is always allowed. This mode is useful for setting up IEEE 802.1X switches. For example, enabling IEEE 802.1X authentication in conjunction with
    • ForceAuthorized mode enables IEEE 802.1X to be activated successively. In ForceAuthorized mode, for example, internal IEEE 802.1X functionality tests can be performed on the switch before activating the productive "auto" mode, which forces all supplicants to authenticate.
    • Auto: Requires successful authentication from the supplicant. If the supplicant has successfully authenticated, access is granted, otherwise it remains blocked.

      The PAE can assume a supplicant or authenticator functionality.

  • Authentication Server (AS) 
    The AS provides an authentication service to the Authenticator. The AS is usually installed in the protected network and does not need to authenticate itself. In practice, the AS can be a RADIUS server service, as provided freely by the FreeRadius project, for example. If the operating systems Windows 2000 or Windows 2003 are used, a RADIUS server can be operated with the "Internet Authentication Service" (IAS). Every major manufacturer of switches and routers also provides its own RADIUS implementation, please refer to the product offerings of the respective manufacturers.
    The credentials to be checked can be located directly on the AS in the form of a simple text file, but the AS can also access a database service using database drivers. The back-end possibilities are theoretically unlimited for an AS. In practice, an LDAP connection is often preferred. The advantage is obvious: Existing domain user IDs already exist in the Active Directory Service (ADS) of Microsoft operating systems. In the case of free LDAP implementations, it can also be the OpenLDAP3 service, which is suitable for LDAP operation. The manifold backend possibilities of the RADIUS server are therefore also advantages for the use of IEEE 802.1X. This example clearly shows that the IEEE 802.1X standard is based on existing interfaces and thus strives to be practical.
    In the context of RADIUS terminology, the term network access server (NAS) is used instead of the term "authenticator". Dialing computers regard the NAS as a server. From the RADIUS server's point of view, the NAS is a client.
    The range of services and the user ID (assignment of the VLAN) 

     access accept messages from the Authentication Server to the Authenticator are a major advantage when using IEEE 802.1X. RFC 2869 "RADIUS Extensions" describes a large number of attributes that are sent from the AS to the authenticator. Three interesting attributes are called "Tunnel-Type", "Tunnel-Medium-Type" and "Tunnel-Private-Group-Id". At the end of RADIUS authentication, the RADIUS server sends an access accept message to the network access server. If these three attributes are appended to the Access Accept message, the NAS will request that the supplicant be assigned to the relevant VLAN. The VLAN ID is located exactly in the attribute "Tunnel-Private-Group-Id" of the reply packet. The NAS switches the port from the guest VLAN to the VLAN intended for the supplicant. In practice, this means that the user information that the authenticator sends to the AS can be used to provide an adapted range of services for the supplicant. On Linux, BSD or Windows servers it is relatively easy today to implement several VLANs and thus provide a selection of services for each VLAN.


Related Links:


IEEE 802.1X ist ein Standard zur Authentifizierung in Rechnernetzen.

Der Standard IEEE 802.1X stellt eine generelle Methode für die Authentifizierung und Autorisierung in IEEE-802-Netzen zur Verfügung. Am Netzwerkzugang, einem physischen Port im LAN, einem logischen IEEE 802.1Q VLAN oder einem WLAN, erfolgt die Authentifizierung eines Teilnehmers durch den Authenticator, der mittels eines Authentifizierungsservers (RADIUS-Server) die durch den Teilnehmer (Supplikant) übermittelten Authentifizierungsinformationen prüft und gegebenenfalls den Zugriff auf die durch den Authenticator angebotenen Dienste (LAN, VLAN oder WLAN) zulässt oder abweist.

Durch diese Möglichkeit der Nutzung eines Authentifizierungsservers kann auch lokal unbekannten Teilnehmern der Netzzugang ermöglicht werden. Zum Beispiel können Angehörige vieler Hochschulen mittels eduroam an anderen Hochschulen WLAN nutzen, ohne dass dort ein für jedermann offener Gastzugang oder ähnliches eingerichtet zu werden braucht.

Der Standard empfiehlt das Extensible Authentication Protocol (EAP) oder das PPP-EAP-TLS Authentication Protocol zur Authentifizierung, da keine eigenen Authentisierungsprotokolle definiert werden.

Bei der Schreibweise ist laut IEEE ein Großbuchstabe zu verwenden, da IEEE 802.1X ein alleinstehender Standard ist und keine Ergänzung eines bestehenden Standards.

  • Supplicant 
    Supplicants (deutsch Bittsteller) sind alle IEEE 802.1X-authentifizierfähigen Geräte (s. IEEE 802.1X Artikel 5.1 „Requirements“), die sich gemäß Netzwerkregel am Netzwerk authentifizieren müssen, bevor dem Netzwerkgerät der Zugriff auf die Ressourcen des Netzwerks erlaubt wird.
    In der Praxis wird der Supplicant in Form einer Softwareimplementierung umgesetzt. Beispielsweise unterstützt Windows XP (inkl. SP2) eine Supplicant-Implementierung nativ. Weiterhin kann man sich auch der freien Supplicant-Implementierungen aus den Projekten von Open1x oder SecureW2 bedienen, um eine IEEE-802.1X-Infrastruktur aufzubauen. Nicht alle Netzwerkkomponenten (wie z. B. Netzwerkdrucker) sind jedoch in der Lage, sich über IEEE 802.1X am Netzwerk zu authentifizieren. Oft fehlt alter und sogar neuerer Hardware die IEEE 802.1X Supplicant-Implementierung. Diese Tatsache stellt bei der Einführung von IEEE 802.1X in Produktivsystemen den größten Kritikpunkt an IEEE 802.1X dar. Einige Switches stellen für dieses Problem z. B. die „MAC-Bypass“-Funktion bereit. Damit ist es möglich, das Netzwerkgerät anhand der MAC-Adresse zu authentifizieren. Somit können auch Geräte authentifiziert werden, die keine IEEE-802.1X-Supplicant-Implementierung besitzen.

  • Authenticator 
    Zwischen dem Supplicant und dem zu schützenden Netzwerk existiert der Authenticator. Die Rolle des Authenticators ist es, die Authentizität des Supplicants zu überprüfen, ähnlich der Rolle eines Türstehers im Rahmen einer Ausweiskontrolle. Kann sich der Supplicant gegenüber dem Authenticator erfolgreich mit gültigen Credentials (zu dt. „Berechtigungsnachweis“ oder „Legitimation“) ausweisen, wird dem Supplicant der Zugriff auf das Netzwerk durch den Authenticator gewährt. Schlägt die Authentifizierung fehl, wird der Zugriff verweigert. Der Authenticator kann in der Praxis ein IEEE 802.1X-fähiger Switch, Router oder IEEE 802.11-WLAN-Access-Point sein. Die Credentials werden i. d. R. von dem Authenticator bei einem „Authentication Server“ (AS) angefragt. Der Authentication-Server findet sich im IEEE-802.1X-Modell in einem vertrauenswürdigen Netzwerk wieder.

  • Port Access Entity: PAE 
    Die PAE, welche in der Praxis als Port am Switch vorgestellt werden kann, implementiert hierbei einen Zustandsautomaten, indem immer der jeweilige Authentifizierungszustand zwischen Supplicant und Authenticator am kontrollierten Port abgebildet ist. Der IEEE 802.1X sieht für die Zugriffseinstellung im PAE drei mögliche Zugriffsmodi für Supplicants vor:
  • ForceUnauthorized: Der kontrollierte Port ist im Modus „nicht bevollmächtigt“. Dabei wird jeder Zugriff eines Supplicants blockiert. Es ist egal, ob sich der Supplicant erfolgreich authentifizieren kann oder nicht, in jedem Fall wird der Zugriff gesperrt.
  • ForceAuthorized: Das Gegenteil von ForceUnauthorized. Der kontrollierte Port ist im Modus „autorisiert“. Dabei wird dem Supplicant der Zugriff immer gewährt. Es ist nicht wichtig, ob sich der Supplicant gegenüber dem Authenticator authentifizieren kann, in jedem Fall wird der Zugriff gestattet. Dieser Modus ist für die praktische Einrichtung von IEEE 802.1X-Switches interessant. Mit der Aktivierung der IEEE 802.1X-Authentifizierung in Verbindung mit dem ForceAuthorized-Modus ist z. B. eine sukzessive Aktivierung von IEEE 802.1X möglich. Im ForceAuthorized-Modus können z. B. am Switch interne Tests zur IEEE-802.1X-Funktionstauglichkeit vorgenommen werden, bevor anschließend der produktive „Auto“-Modus aktiviert wird, der alle Supplicants zum Authentifizieren zwingt.
  • Auto: Verlangt eine erfolgreiche Authentifizierung von dem Supplicant. Wenn sich der Supplicant erfolgreich authentifiziert hat, wird der Zugriff gewährt, andernfalls bleibt er weiterhin gesperrt. 

    Die PAE kann eine Supplicant- oder Authenticatorfunktionalität annehmen.

  • Authentication Server (AS) 
    Der AS stellt dem Authenticator einen Authentifizierungsdienst bereit. Dabei ist der AS in der Regel im geschützten Netz installiert und braucht sich nicht zu authentifizieren. Der AS kann in der Praxis ein RADIUS-Serverdienst sein, wie ihn z. B. das FreeRadius-Projekt frei bereitstellt. Werden die Betriebssysteme Windows 2000 oder Windows 2003 genutzt, so kann mit dem „Internet Authentication Service“ (IAS) ein RADIUS-Server betrieben werden. Jeder größere Hersteller von Switches und Routern stellt auch eine eigene RADIUS-Implementierung bereit, hier sei auf das Produktangebot der jeweiligen Hersteller verwiesen.
    Die zu überprüfenden Credentials können direkt auf dem AS liegen, in Form einer einfachen Textdatei, der AS kann aber auch durch Datenbanktreiber auf einen Datenbankdienst zugreifen. Die Back-End-Möglichkeiten sind in der Theorie für einen AS unbegrenzt. 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. Im Fall von freien LDAP-Implementierungen kann es auch der OpenLDAP3-Dienst sein, der sich für einen LDAP-Betrieb eignet. Die vielfältigen Backend-Möglichkeiten des RADIUS-Servers sind somit auch Vorteile für den Einsatz von IEEE 802.1X. An diesem Beispiel ist gut zu erkennen, dass der IEEE-802.1X-Standard auf vorhandene Schnittstellen aufsetzt und somit bemüht ist, praxistauglich zu sein.
    Im Kontext der RADIUS-Terminologie wird statt des Begriffs „Authenticator“ der Begriff Network Access Server (NAS) verwendet. Einwählende Computer betrachten den NAS als Server. Aus der Sicht des RADIUS-Servers ist der NAS hingegen ein Client. 
    Das Dienstspektrum und die Benutzerkennung (Zuordnung des VLANs) 

    Einen großen Vorteil bei der Nutzung von IEEE 802.1X bilden die RADIUS-Access-Accept-Nachrichten vom Authentication Server zum Authenticator. Das RFC 2869 „RADIUS Extensions“ beschreibt eine große Menge an Attributen, die vom AS an den Authenticator gesendet werden. Drei interessante Attribute heißen hierbei „Tunnel-Type“, „Tunnel-Medium-Type“ und „Tunnel-Private-Group-Id“. Am Ende der RADIUS-Authentifizierung sendet der RADIUS-Server an den Network-Access-Server eine Access-Accept-Nachricht. Werden diese drei Attribute an die Access-Accept-Nachricht angehängt, wird damit vom NAS gefordert, den Supplicant in das betreffende VLAN zu zuweisen. Die VLAN-ID steht hierbei genau im Attribut „Tunnel-Private-Group-Id“ des Antwortpakets. Der NAS schaltet hierbei den Port vom Gast-VLAN in das für den Supplicant bestimmte VLAN um. Für die Praxis bedeutet es, dass anhand der Benutzerinformationen, die der Authenticator an den AS sendet, im Gegenzug ein angepasstes Dienstspektrum für den Supplicant stattfinden kann. Auf Linux-, BSD- oder Windowsservern ist es heute relativ leicht, mehrere VLANs umzusetzen und damit je VLAN eine Auswahl an Diensten bereitzustellen.


Verwandte Artikel:

Content by Label
cqllabel = "network"