View source for IEEE 802.1X

{{short description|IEEE standard for port-based network access control}}

'''IEEE 802.1X''' is an [[IEEE Standard]] for port-based [[network access control]] (PNAC). It is part of the [[IEEE 802.1]] group of networking protocols.  It provides an [[authentication]] mechanism to devices wishing to attach to a [[LAN]] or [[WLAN]].

The standard directly addresses an attack technique called Hardware Addition<ref>{{Cite web |date=2018-04-18 |title=Hardware Additions, Technique T1200 |url=https://attack.mitre.org/techniques/T1200/ |access-date=2024-04-10 |website=attack.mitre.org |language=en-US}}</ref> where an attacker posing as a guest, customer or staff smuggles a hacking device into the building that they then plug into the network giving them full access. A notable example of the issue occurred in 2005 when a machine attached to [[Walmart]]'s network hacked thousands of their servers.<ref>{{Cite magazine |last=Zetter |first=Kim |title=Big-Box Breach: The Inside Story of Wal-Mart's Hacker Attack |url=https://www.wired.com/2009/10/walmart-hack/ |access-date=2024-02-07 |magazine=Wired |language=en-US |issn=1059-1028}}</ref> 

IEEE 802.1X defines the encapsulation of the [[Extensible Authentication Protocol]] (EAP) over wired [[IEEE 802]] networks{{Ref RFC|3748|rsection=3.3}} and over 802.11 wireless networks,{{Ref RFC|3748|rsection=7.12}} which is known as "EAP over LAN" or EAPOL.<ref>IEEE 802.1X-2001, § 7</ref> EAPOL was originally specified for [[IEEE 802.3]] Ethernet, [[IEEE 802.5]] Token Ring, and [[FDDI]] (ANSI X3T9.5/X3T12 and ISO 9314) in 802.1X-2001,<ref>IEEE 802.1X-2001, § 7.1 and 7.2</ref> but was extended to suit other IEEE 802 LAN technologies such as [[IEEE 802.11]] wireless in 802.1X-2004.<ref>IEEE 802.1X-2004, § 7.6.4</ref> The EAPOL was also modified for use with [[IEEE 802.1AE]] ("MACsec") and [[IEEE 802.1#802.1AR|IEEE 802.1AR]] (Secure Device Identity, DevID) in 802.1X-2010<ref name="802.1X-2010_seciv">IEEE 802.1X-2010, page iv</ref><ref name="802.1X-2010_sec5">IEEE 802.1X-2010, § 5</ref> to support service identification and optional point to point encryption over the internal LAN segment. 802.1X is part of the [[logical link control]] (LLC) sublayer of the 802 reference model.<ref>{{cite tech report |institution=[[IEEE]] |doi=10.1109/IEEESTD.2014.6847097 |title=IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture |number=[[IEEE 802|802]] |year=2014 |quote=802.1X forms part of the LLC sublayer and provides a secure, connectionless service immediately above the MAC sublayer.}}</ref>

==Overview==
[[Image:802.1X wired protocols.png|444px|thumb|right|EAP data is first encapsulated in EAPOL frames between the Supplicant and Authenticator, then re-encapsulated between the Authenticator and the Authentication server using RADIUS or [[Diameter (protocol)|Diameter]].]]
802.1X authentication involves three parties: a supplicant, an authenticator, and an authentication server. The '''[[Supplicant (computer)|supplicant]]''' is a [[Client (computing)|client]] device (such as a laptop) that wishes to attach to the LAN/WLAN. The term 'supplicant' is also used interchangeably to refer to the software running on the client that provides credentials to the authenticator. The '''[[authenticator]]''' is a network device that provides a data link between the client and the network and can allow or block network traffic between the two, such as an [[Ethernet switch]] or [[wireless access point]]; and the '''authentication server''' is typically a trusted server that can receive and respond to requests for network access, and can tell the authenticator if the connection is to be allowed, and various settings that should apply to that client's connection or setting. Authentication servers typically run software supporting the [[RADIUS]] and [[Extensible Authentication Protocol|EAP]] protocols. In some cases, the authentication server software may be running on the authenticator hardware.

The authenticator acts like a security guard to a protected network. The supplicant (i.e., client device) is not allowed access through the authenticator to the protected side of the network until the supplicant's identity has been validated and authorized. With 802.1X port-based authentication, the supplicant must initially provide the required credentials to the authenticator - these will have been specified in advance by the network administrator and could include a user name/password or a permitted [[digital certificate]]. The authenticator forwards these credentials to the authentication server to decide whether access is to be granted. If the authentication server determines the credentials are valid, it informs the authenticator, which in turn allows the supplicant (client device) to access resources located on the protected side of the network.<ref>{{cite web|title=802.1X Port-Based Authentication Concepts|url=http://www.wireless-nets.com/resources/downloads/802.1x_C2.html|access-date=2008-07-30|archive-url=https://web.archive.org/web/20121014224422/http://www.wireless-nets.com/resources/downloads/802.1x_C2.html|archive-date=2012-10-14}}</ref>

==Protocol operation==
EAPOL operates over the [[data link layer]], and in [[Ethernet II framing]] protocol has an [[EtherType]] value of 0x888E.

===Port entities===
802.1X-2001 defines two logical port entities for an authenticated port—the "controlled port" and the "uncontrolled port". The controlled port is manipulated by the 802.1X PAE (Port Access Entity) to allow (in the authorized state) or prevent (in the unauthorized state) network traffic ingress and egress to/from the controlled port. The uncontrolled port is used by the 802.1X PAE to transmit and receive EAPOL frames.

802.1X-2004 defines the equivalent port entities for the supplicant; so a supplicant implementing 802.1X-2004 may prevent higher-level protocols from being used if it is not content that authentication has successfully completed. This is particularly useful when an EAP method providing [[mutual authentication]] is used, as the supplicant can prevent data leakage when connected to an unauthorized network.

===Typical authentication progression===
The typical authentication procedure consists of:
[[File:802-1X.png|thumb|Sequence diagram of the 802.1X progression (initiated by the supplicant)|444x444px]]
# '''Initialization''' On detection of a new supplicant, the port on the switch (authenticator) is enabled and set to the "unauthorized" state. In this state, only 802.1X traffic is allowed; other traffic, such as the [[Internet Protocol]] (and with that [[Transmission Control Protocol|TCP]] and [[User Datagram Protocol|UDP]]), is dropped.
# '''Initiation''' To initiate authentication the authenticator will periodically transmit EAP-Request Identity frames to a special Layer 2 [[MAC address]] ({{MACaddr|01:80:C2:00:00:03}}) on the local network segment. The supplicant listens at this address, and on receipt of the EAP-Request Identity frame, it responds with an EAP-Response Identity frame containing an identifier for the supplicant such as a User ID. The authenticator then encapsulates this Identity response in a [[RADIUS]] Access-Request packet and forwards it on to the authentication server. The supplicant may also initiate or restart authentication by sending an EAPOL-Start frame to the authenticator, which will then reply with an EAP-Request Identity frame.
# '''Negotiation''' ''(Technically EAP negotiation)'' The authentication server sends a reply (encapsulated in a [[RADIUS]] Access-Challenge packet) to the authenticator, containing an EAP Request specifying the EAP Method (The type of EAP based authentication it wishes the supplicant to perform). The authenticator encapsulates the EAP Request in an EAPOL frame and transmits it to the supplicant. At this point, the supplicant can start using the requested EAP Method, or do a NAK ("Negative Acknowledgement") and respond with the EAP Methods it is willing to perform.
# '''Authentication''' If the authentication server and supplicant agree on an EAP Method, EAP Requests and Responses are sent between the supplicant and the authentication server (translated by the authenticator) until the authentication server responds with either an EAP-Success message (encapsulated in a [[RADIUS]] Access-Accept packet), or an EAP-Failure message (encapsulated in a [[RADIUS]] Access-Reject packet). If authentication is successful, the authenticator sets the port to the "authorized" state and normal traffic is allowed. If it is unsuccessful, the port remains in the "unauthorized" state. When the supplicant logs off, it sends an EAPOL-logoff message to the authenticator, the authenticator then sets the port to the "unauthorized" state, once again blocking all non-EAP traffic.

==Implementations==
{{Advert section|date=March 2024}}
An open-source project named [[Open1X]] produces a client, [[Xsupplicant]]. This client is currently available for both Linux and Windows. The main drawbacks of the Open1X client are that it does not provide comprehensible and extensive user documentation and that most Linux vendors do not provide a package for it.  The more general [[wpa_supplicant]] can be used for [[802.11]] wireless networks and wired networks.  Both support a very wide range of EAP types.<ref>{{cite web|url=https://w1.fi/cgit/hostap/plain/wpa_supplicant/eap_testing.txt |title=eap_testing.txt from wpa_supplicant |access-date=2010-02-10}}</ref>

The [[iPhone]] and [[iPod Touch]] support 802.1X since the release of [[iOS]] 2.0.
[[Android (operating system)|Android]] has support for 802.1X since the release of 1.6 Donut.
[[ChromeOS]] has supported 802.1X since mid-2011.<ref>{{cite web|url = https://cloud.googleblog.com/2011/08/the-computer-that-keeps-getting-better.html |title = The computer that keeps getting better |first=Rajen |last=Sheth |date=August 10, 2011 |website=Google Cloud Official Blog |access-date = 2022-07-02}}</ref>

[[macOS]] has offered native support since [[Mac OS X Panther]].<ref>{{cite book|url = https://books.google.com/books?id=Tdr5DIxmQYgC&pg=PA19 |title = Mac OS X Unwired: A Guide for Home, Office, and the Road |first1 = Tom |last1 = Negrino |first2 = Dori |last2 = Smith| page = 19 |isbn = 978-0596005085 |publisher = [[O'Reilly Media]] |date = 2003 |access-date = 2022-07-02}}</ref>

[[Avenda Systems]] provides a supplicant for [[Windows]], [[Linux]] and [[macOS]].  They also have a plugin for the Microsoft [[Network Access Protection|NAP]] framework.<ref>{{cite web|url=https://docs.microsoft.com/en-us/archive/blogs/nap/nap-clients-for-linux-and-macintosh-are-available |title=NAP clients for Linux and Macintosh are available |work=Network Access Protection (NAP) team blog |date=2008-12-16}}</ref> Avenda also offers health checking agents.

=== Windows ===

Windows defaults to not responding to 802.1X authentication requests for 20 minutes after a failed authentication. This can cause significant disruption to clients.

The block period can be configured using the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\dot3svc\BlockTime<ref>{{cite web|url=https://docs.microsoft.com/en-us/archive/blogs/jeff_stokes/20-minute-delay-deploying-windows-7-on-802-1x-fix-it-here |title=20 minute delay deploying Windows 7 on 802.1x? Fix it here!|work=Dude where's my PFE? blog|date=2013-01-24}}</ref> DWORD value (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\wlansvc\BlockTime for wireless networks) in the registry (entered in minutes).  A [[hotfix]] is required for Windows XP SP3 and Windows Vista SP2 to make the period configurable.<ref>{{cite web|url=https://support.microsoft.com/en-us/topic/a-windows-xp-based-windows-vista-based-or-windows-server-2008-based-computer-does-not-respond-to-802-1x-authentication-requests-for-20-minutes-after-a-failed-authentication-8fcef6e5-4526-17db-e430-22f1f51a84ad |title=A Windows XP-based, Windows Vista-based or Windows Server 2008-based computer does not respond to 802.1X authentication requests for 20 minutes after a failed authentication |website=Microsoft Support |date=2009-09-17 |access-date=2022-07-03}}</ref>

[[Wildcard certificate|Wildcard]] server certificates are not supported by EAPHost, the Windows component that provides EAP support in the operating system.<ref>{{cite web|url=https://docs.microsoft.com/en-us/previous-versions/cc730460(v=msdn.10)?redirectedfrom=MSDN |title=EAPHost in Windows Vista and Longhorn (January 18, 2006) |website=Microsoft Docs |date=2007-01-18 |access-date=2022-07-03}}</ref> The implication of this is that when using a commercial certification authority, individual certificates must be purchased.

==== Windows XP ====

Windows XP has major issues with its handling of IP address changes resulting from user-based 802.1X authentication that changes the VLAN and thus subnet of clients.<ref>{{cite web|url=http://support.microsoft.com/kb/935638 |title=You experience problems when you try to obtain Group Policy objects, roaming profiles, and logon scripts from a Windows Server 2003-based domain controller |website=Microsoft Support |date=2007-09-14 |access-date=2010-02-10 |archive-url=https://web.archive.org/web/20080422000723/http://support.microsoft.com/kb/935638 |archive-date=2008-04-22}}</ref> Microsoft has stated that it will not backport the [[Single sign-on|SSO]] feature from Vista that resolves these issues.<ref>{{cite web|url=http://social.technet.microsoft.com/forums/en-US/winserverNAP/thread/f68dc3f0-744a-4d0f-b85a-87f8bc531fd0/ |title=802.1x with dynamic vlan switching - Problems with Roaming Profiles |quote=With Vista, this is not a problem at all with the SSO feature, however, this feature does not exist in XP and unfortunately, we do not have any plans to backport this feature to XP as it is just too complex a change. |website=Microsoft TechNet Forums |access-date=2010-02-10 |archive-url=https://web.archive.org/web/20110824194607/http://social.technet.microsoft.com/forums/en-US/winserverNAP/thread/f68dc3f0-744a-4d0f-b85a-87f8bc531fd0/ |archive-date=2011-08-24}}</ref>

If users are not logging in with roaming profiles, a hotfix must be downloaded and installed if authenticating via PEAP with PEAP-MSCHAPv2.<ref>{{cite web|url=http://support.microsoft.com/kb/969111 |title=A Windows XP Service Pack 3-based client computer cannot use the IEEE 802.1X authentication when you use PEAP with PEAP-MSCHAPv2 in a domain |website=Microsoft support |date=2009-04-23 |access-date=2010-03-23 |archive-url=https://web.archive.org/web/20100316162915/http://support.microsoft.com/kb/969111 |archive-date=2010-03-16}}</ref>

==== Windows Vista ====

Windows Vista-based computers that are connected via an IP phone may not authenticate as expected and, as a result, the client can be placed into the wrong VLAN.  A hotfix is available to correct this.<ref name="Support.microsoft.com">{{cite web|url=https://support.microsoft.com/en-us/topic/a-computer-that-is-connected-to-an-ieee-802-1x-authenticated-network-via-another-802-1x-enabled-device-does-not-connect-to-the-correct-network-1ab27ed2-3ccb-fc02-19d2-5fb36b4c0bf2 |title= A computer that is connected to an IEEE 802.1X authenticated network through a VOIP phone does not connect to the correct network after you resume it from Hibernate mode or Sleep mode |website=Microsoft Support |date=2010-02-08 |access-date=2022-07-03}}</ref>

==== Windows 7 ====

Windows 7 based computers that are connected via an IP phone may not authenticate as expected and, consequently, the client can be placed into the wrong VLAN.  A hotfix is available to correct this.<ref name="Support.microsoft.com"/>

Windows 7 does not respond to 802.1X authentication requests after initial 802.1X authentication fails.  This can cause significant disruption to clients.  A hotfix is available to correct this.<ref>{{cite web|url=http://support.microsoft.com/kb/980295 |title=No response to 802.1X authentication requests after authentication fails on a computer that is running Windows 7 or Windows Server 2008 R2 |website=Microsoft Support |date=2010-03-08 |access-date=2010-03-23 |archive-url=https://web.archive.org/web/20101114001734/http://support.microsoft.com/kb/980295 |archive-date=2010-11-14}}</ref>

==== Windows PE ====

[[Windows PE]] does not have native support for 802.1X.  However, support can be added to WinPE 2.1<ref>{{cite web|url=http://support.microsoft.com/kb/975483 |title=Windows PE 2.1 does not support the IEEE 802.1X authentication protocol |website=Microsoft Support |date=2009-12-08 |access-date=2010-02-10 |archive-url=https://web.archive.org/web/20100305170820/http://support.microsoft.com/kb/975483 |archive-date=2010-03-05}}</ref> and WinPE 3.0<ref>{{cite web|url=https://support.microsoft.com/en-us/topic/the-ieee-802-1x-authentication-protocol-is-not-supported-in-windows-preinstall-environment-pe-3-0-a3f0be1d-e688-4925-53ef-49a4139aae3a |title=The IEEE 802.1X authentication protocol is not supported in Windows Preinstall Environment (PE) 3.0 |website=Microsoft Support |date=2009-12-08 |access-date=2022-07-03}}</ref> through hotfixes that are available from Microsoft.  Although full documentation is not yet available, preliminary documentation for the use of these hotfixes is available via a Microsoft blog.<ref>{{cite web|url=http://blogs.technet.com/deploymentguys/archive/2010/03/02/adding-support-for-802-1x-to-winpe.aspx |title=Adding Support for 802.1X to WinPE |work=The Deployment Guys blog |date=2010-03-02 |access-date=2010-03-03 |archive-url=https://web.archive.org/web/20110617114548/http://blogs.technet.com/b/deploymentguys/archive/2010/03/02/adding-support-for-802-1x-to-winpe.aspx |archive-date=2011-06-17}}</ref>

=== Linux ===

Most [[Linux distribution]]s support 802.1X via [[wpa_supplicant]] and desktop integration like [[NetworkManager]].

=== Apple devices ===
As of [[iOS 17]] and [[macOS 14]], Apple devices support connecting to 802.1X networks using [[Extensible Authentication Protocol|EAP-TLS]] with TLS 1.3 (EAP-TLS 1.3). Additionally, devices running iOS/iPadOS/tvOS 17 or later support wired 802.1X networks.<ref>{{cite web|url=https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-17-release-notes |title=iOS 17 beta 4 developer release notes |website=Apple Developer |date=2023-07-25 |access-date=2023-07-25}}</ref><ref>{{cite web|url=https://developer.apple.com/documentation/macos-release-notes/macos-14-release-notes |title=macOS 14 beta 4 developer release notes |website=Apple Developer |date=2023-07-25 |access-date=2023-07-25}}</ref>

===Federations===
[[eduroam]] (the international roaming service), mandates the use of 802.1X authentication when providing network access to guests visiting from other eduroam-enabled institutions.<ref>{{cite web|url = https://eduroam.org/how/
 |title = How does eduroam work? |website = [[eduroam]] |access-date = 2022-07-03}}</ref>

[[BT Group|BT]] (British Telecom, PLC) employs Identity Federation for authentication in services delivered to a wide variety of industries and governments.<ref>{{cite web|url = http://www.ca.com/files/SuccessStories/bt_ss_165270.pdf
 |title = BT Identity and Access Management |access-date = 2010-08-17 | archive-url = https://web.archive.org/web/20110613160018/http://www.ca.com/files/SuccessStories/bt_ss_165270.pdf | archive-date = 2011-06-13}}</ref>

== Proprietary extensions ==

=== MAB (MAC Authentication Bypass) ===
Not all devices support 802.1X authentication.  Examples include network printers, Ethernet-based electronics like environmental sensors, cameras, and wireless phones. For those devices to be used in a protected network environment, alternative mechanisms must be provided to authenticate them.

One option would be to disable 802.1X on that port, but that leaves that port unprotected and open for abuse. Another slightly more reliable option is to use the MAB option. When MAB is configured on a port, that port will first try to check if the connected device is 802.1X compliant, and if no reaction is received from the connected device, it will try to authenticate with the AAA server using the connected device's [[MAC address]] as username and password. The network administrator then must make provisions on the [[RADIUS]] server to authenticate those MAC addresses, either by adding them as regular users or implementing additional logic to resolve them in a network inventory database.

Many managed Ethernet switches<ref>{{cite web|title=Dell PowerConnect 6200 series CLI Guide|url=http://support.dell.com/support/edocs/network/pc62xx/en/CLI/PDF/cli_en.pdf|archive-url=https://web.archive.org/web/20121118212447/http://support.dell.com/support/edocs/network/PC62xx/en/CLI/PDF/cli_en.pdf |archive-date=2012-11-18|page=622, Revision: A06-March 2011|access-date=26 January 2013}}</ref>  offer options for this.

==Vulnerabilities in 802.1X-2001 and 802.1X-2004==

===Shared media===
In the summer of 2005, Microsoft's Steve Riley posted an article (based on the original research of Microsoft MVP Svyatoslav Pidgorny) detailing a serious vulnerability in the 802.1X protocol, involving a [[man-in-the-middle attack]]. In summary, the flaw stems from the fact that 802.1X authenticates only at the beginning of the connection, but after that authentication, it's possible for an attacker to use the authenticated port if they have the ability to physically insert themselves (perhaps using a workgroup hub) between the authenticated computer and the port. Riley suggests that for wired networks the use of [[IPsec]] or a combination of IPsec and 802.1X would be more secure.<ref>{{cite web|url=https://docs.microsoft.com/en-us/previous-versions/tn-archive/cc512611(v=technet.10) |title=Mitigating the Threats of Rogue Machines—802.1X or IPsec? |first=Steve |last=Riley |website=Microsoft Docs |date=2005-08-09 |access-date=2022-07-03}}</ref>

EAPOL-Logoff frames transmitted by the 802.1X supplicant are sent in the clear and contain no data derived from the credential exchange that initially authenticated the client.<ref>IEEE 802.1X-2001, § 7.1</ref> They are therefore trivially easy to spoof on shared media and can be used as part of a targeted [[DoS]] on both wired and wireless LANs. In an EAPOL-Logoff attack a malicious third party, with access to the medium the authenticator is attached to, repeatedly sends forged EAPOL-Logoff frames from the target device's MAC Address. The authenticator (believing that the targeted device wishes to end its authentication session) closes the target's authentication session, blocking traffic ingressing from the target, denying it access to the network.

The 802.1X-2010 specification, which began as 802.1af, addresses vulnerabilities in previous 802.1X specifications, by using MACsec [[IEEE 802.1AE]] to encrypt data between logical ports (running on top of a physical port) and [[IEEE 802.1AR]] (Secure Device Identity / DevID) authenticated devices.<ref name="802.1X-2010_seciv"/><ref name="802.1X-2010_sec5">IEEE 802.1X-2010, § 5</ref><ref>{{cite web|url=http://standards.ieee.org/board/rev/110early.html |title=2 February 2010 Early Consideration Approvals |publisher=[[IEEE]] |access-date=2010-02-10 |archive-url=https://web.archive.org/web/20100706171048/http://standards.ieee.org/board/rev/110early.html |archive-date=2010-07-06}}</ref><ref>{{cite web|url=http://www.ieee802.org/1/pages/802.1x-2010.html |title=IEEE 802.1: 802.1X-2010 - Revision of 802.1X-2004 |publisher=Ieee802.org |date=2010-01-21 |access-date=2010-02-10 |archive-url=https://web.archive.org/web/20100304232216/http://www.ieee802.org/1/pages/802.1x-2010.html |archive-date=2010-03-04}}</ref>

As a stopgap, until these enhancements are widely implemented, some vendors have extended the 802.1X-2001 and 802.1X-2004 protocol, allowing multiple concurrent authentication sessions to occur on a single port. While this prevents traffic from devices with unauthenticated MAC addresses ingressing on an 802.1X authenticated port, it will not stop a malicious device snooping on traffic from an authenticated device and provides no protection against [[MAC spoofing]], or EAPOL-Logoff attacks.

== Alternatives ==
The [[IETF]]-backed alternative is the [[Protocol for Carrying Authentication for Network Access]] (PANA), which also carries EAP, although it works at layer 3, using UDP, thus not being tied to the 802 infrastructure.<ref name="GoldenDedieu2007">{{cite book|author1=Philip Golden|author2=Hervé Dedieu|author3=Krista S. Jacobsen|title=Implementation and Applications of DSL Technology|url=https://books.google.com/books?id=Jjkd74jY47oC&pg=PA483|year=2007|publisher=Taylor & Francis|isbn=978-1-4200-1307-8|pages=483–484}}</ref>

==See also==
*[[AEGIS SecureConnect]]
*[[IEEE 802.11i-2004]]

==References==
{{reflist}}

==External links==
* [https://1.ieee802.org/security/802-1x/ IEEE page on 802.1X]
* [https://ieeexplore.ieee.org/document/9018454 GetIEEE802 Download 802.1X-2020]
* [https://web.archive.org/web/20110805233403/http://standards.ieee.org/getieee802/download/802.1X-2010.pdf GetIEEE802 Download 802.1X-2010]
* [https://web.archive.org/web/20060602062707/http://standards.ieee.org/getieee802/download/802.1X-2004.pdf GetIEEE802 Download 802.1X-2004]
* [https://web.archive.org/web/20040619233749/http://standards.ieee.org/getieee802/download/802.1X-2001.pdf GetIEEE802 Download 802.1X-2001]
* [http://www.techrepublic.com/article/ultimate-wireless-security-guide-self-signed-certificates-for-your-radius-server/6148560 Ultimate wireless security guide: Self-signed certificates for your RADIUS server]
* [http://wire.cs.nctu.edu.tw/wire1x/ WIRE1x] {{Webarchive|url=https://web.archive.org/web/20150822030324/http://wire.cs.nctu.edu.tw/wire1x/ |date=2015-08-22 }}
* [https://technet.microsoft.com/en-us/network/bb545365.aspx Wired Networking with 802.1X Authentication] on Microsoft TechNet

{{IEEE standards}}

[[Category:IEEE 802|IEEE 802.01x]]
[[Category:Networking standards]]
[[Category:Computer access control protocols]]
[[Category:Computer network security]]