Concept 802.1X: Difference between revisions
Jump to navigation
Jump to search
m (added section "Debugging") |
No edit summary |
||
| Line 1: | Line 1: | ||
=Info= | =Info= | ||
'''802.1X,''' Port-Based Network Control, is an IEEE standard. The standard allows | '''802.1X,''' Port-Based Network Control, is an IEEE standard. The standard allows network devices to perform an authentication handshake within the 802.3 link layer (Ethernet). | ||
The authentication is encapsulated within EAP over LAN (EAPOL) frames. No other traffic, except EAPOL is allowed prior to a successful authentication | The authentication is encapsulated within EAP over LAN (EAPOL) frames. No other traffic, except EAPOL is allowed prior to a successful authentication. | ||
802.1X must not be considered a bullet-proof security mechanism, since all traffic following the authentication phase is not authenticated. | |||
The standard specifies the following parties participating in an 802.1X authentication: | The standard specifies the following parties participating in an 802.1X authentication: | ||
* Supplicant: The party supplying credentials towards an authenticator on the other side of a point-to-point link. | * Supplicant: The party supplying credentials towards an authenticator on the other side of a point-to-point link. For example an IP phone fulfills a supplicant's role. | ||
** innovaphones | ** innovaphones IP-phones are configured to support pass-through of EAPOL messages. That means a PC attached to the PC-port of a phone may also become a supplicant and may 802.1X-authenticate independently and separately. | ||
* Authenticator: The party facilitating the authentication. A switch will usually be the authenticator. | * Authenticator: The party facilitating the authentication. A switch will usually be the authenticator and forward the authentication messages to an configured ''Authentication Server''. | ||
* Authentication Server: The party providing the authentication service to the authenticator. The 802.1X standard mentions a RADIUS server to be an authentication server. | * Authentication Server: The party providing the authentication service to the authenticator. The 802.1X standard mentions a RADIUS server to be an authentication server. | ||
It is the Authenticator/Authentication Server deciding whether EAP-MD5 or EAP-TLS is going to be applied. | It is the Authenticator/Authentication Server deciding whether EAP-MD5 or EAP-TLS is going to be applied. | ||
Please note: innovaphone devices always send an EAP-MD5 authentication first. If this is rejected, an EAP-TLS authentication is sent. | |||
*'''Sample Protocol Flow, EAP-MD5:''' | *'''Sample Protocol Flow, EAP-MD5:''' | ||
[[Image:802dot1x-EAPOL-640x480.gif]] | [[Image:802dot1x-EAPOL-640x480.gif]] | ||
*'''Sample Protocol Flow, EAP-TLS:''' | *'''Sample Protocol Flow, EAP-TLS:''' | ||
[[Image:IP240-eap-tls-success.PNG]] | [[Image:IP240-eap-tls-success.PNG]] | ||
| Line 18: | Line 22: | ||
=Debugging= | =Debugging= | ||
The software module is capable of generating internal trace messages and RPCAP PDUs. Tracing can be enabled by activating a checkmark on the ''/debug.xml'' page of the firmware's web UI. The checkmark is named ''ENET1X0'' (for interface ETH0). The trace buffer can be fetched by a PC connected directly to the PC-port. | The software module is capable of generating internal trace messages and RPCAP PDUs. Tracing can be enabled by activating a checkmark on the ''/debug.xml'' page of the firmware's web UI. The checkmark is named ''ENET1X0'' (for interface ETH0). The trace buffer can be fetched by a PC connected directly to the PC-port. | ||
=Known Limitations= | |||
==EAP-TLS will not work with Windows Server 2016 and later== | |||
The mechanism described above (EAP-MD5 is sent first and EAP-TLS is used only in case of rejection) only works if the authentication server rejects the first request via EAP-MD5. (NAP enforcement) | |||
As described in the [https://docs.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-top Microsoft Knowledgeable] the needed features are not available anymore in ''Windows Server 2016'' | |||
Network Access Protection (NAP), Health Registration Authority (HRA), and Host Credential Authorization Protocol (HCAP) were deprecated in Windows Server 2012 R2, | |||
and are not available in Windows Server 2016. If you have a NAP deployment using operating systems earlier than Windows Server 2016, | |||
you cannot migrate your NAP deployment to Windows Server 2016. | |||
=Related Articles= | |||
* [[Howto:802.1X_EAP-TLS_With_FreeRadius|Howto article: 802.1X EAP-TLS With FreeRadius]] | |||
=Notes= | =Notes= | ||
<references/> | <references/> | ||
[[ | |||
[[Category:Concept|802.1X]] | |||
Revision as of 10:05, 22 September 2021
Info
802.1X, Port-Based Network Control, is an IEEE standard. The standard allows network devices to perform an authentication handshake within the 802.3 link layer (Ethernet). The authentication is encapsulated within EAP over LAN (EAPOL) frames. No other traffic, except EAPOL is allowed prior to a successful authentication. 802.1X must not be considered a bullet-proof security mechanism, since all traffic following the authentication phase is not authenticated.
The standard specifies the following parties participating in an 802.1X authentication:
- Supplicant: The party supplying credentials towards an authenticator on the other side of a point-to-point link. For example an IP phone fulfills a supplicant's role.
- innovaphones IP-phones are configured to support pass-through of EAPOL messages. That means a PC attached to the PC-port of a phone may also become a supplicant and may 802.1X-authenticate independently and separately.
- Authenticator: The party facilitating the authentication. A switch will usually be the authenticator and forward the authentication messages to an configured Authentication Server.
- Authentication Server: The party providing the authentication service to the authenticator. The 802.1X standard mentions a RADIUS server to be an authentication server.
It is the Authenticator/Authentication Server deciding whether EAP-MD5 or EAP-TLS is going to be applied. Please note: innovaphone devices always send an EAP-MD5 authentication first. If this is rejected, an EAP-TLS authentication is sent.
- Sample Protocol Flow, EAP-MD5:
- Sample Protocol Flow, EAP-TLS:
Debugging
The software module is capable of generating internal trace messages and RPCAP PDUs. Tracing can be enabled by activating a checkmark on the /debug.xml page of the firmware's web UI. The checkmark is named ENET1X0 (for interface ETH0). The trace buffer can be fetched by a PC connected directly to the PC-port.
Known Limitations
EAP-TLS will not work with Windows Server 2016 and later
The mechanism described above (EAP-MD5 is sent first and EAP-TLS is used only in case of rejection) only works if the authentication server rejects the first request via EAP-MD5. (NAP enforcement) As described in the Microsoft Knowledgeable the needed features are not available anymore in Windows Server 2016
Network Access Protection (NAP), Health Registration Authority (HRA), and Host Credential Authorization Protocol (HCAP) were deprecated in Windows Server 2012 R2, and are not available in Windows Server 2016. If you have a NAP deployment using operating systems earlier than Windows Server 2016, you cannot migrate your NAP deployment to Windows Server 2016.
Related Articles