Reference11r1:Interfaces/ETH/802.1X: Difference between revisions
Jump to navigation
Jump to search
(New page: '''802.1X,''' Port-Based Network Control, is an IEEE standard. The standard allows LAN devices (wired network cabling!<ref>The standard refers to 802 LANs as a whole, including shared medi...) |
No edit summary |
||
Line 1: | Line 1: | ||
=Info= | |||
'''802.1X,''' Port-Based Network Control, is an IEEE standard. The standard allows LAN devices (wired network cabling!<ref>The standard refers to 802 LANs as a whole, including shared media such as 802.11 WLANs. However, only 802.3 LANs are targeted by the functionality discussed in this article.</ref>) to perform an authentication handshake within the 802.3 link layer (Ethernet). | '''802.1X,''' Port-Based Network Control, is an IEEE standard. The standard allows LAN devices (wired network cabling!<ref>The standard refers to 802 LANs as a whole, including shared media such as 802.11 WLANs. However, only 802.3 LANs are targeted by the functionality discussed in this article.</ref>) 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<ref>It is an authenticator's task to guarantee that non-EAPOL traffic won't be forwarded before an authentication succeeded.</ref><ref>802.1X must not be considered a bullet-proof security mechanism, since all traffic following the authentication phase is not authenticated.</ref>. | The authentication is encapsulated within EAP over LAN (EAPOL) frames. No other traffic, except EAPOL is allowed prior to a successful authentication<ref>It is an authenticator's task to guarantee that non-EAPOL traffic won't be forwarded before an authentication succeeded.</ref><ref>802.1X must not be considered a bullet-proof security mechanism, since all traffic following the authentication phase is not authenticated.</ref>. | ||
Line 7: | Line 8: | ||
* 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. | ||
* 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. | ||
*'''Sample Protocol Flow, EAP-MD5:''' | |||
'''Sample Protocol Flow:''' | |||
[[Image:802dot1x-EAPOL-640x480.gif]] | [[Image:802dot1x-EAPOL-640x480.gif]] | ||
*'''Sample Protocol Flow, EAP-TLS:''' | |||
[[Image:IP240-eap-tls-success.PNG]] | |||
'' | =Configuration= | ||
=='''EAP-MD5'''== | |||
'''EAP- | * '''User''' Enter the user/identity to authenticate with. | ||
* '''User | * '''Password''' Enter the shared secret for the MD5 challenge/response handshake. | ||
* '''Password | =='''EAP-TLS'''== | ||
* '''User''' Enter the user/identity to be sent within the EAP Identity request.<ref name="user-pw">A non-empty user/password just serves as an "on"-switch</ref> | |||
* '''Password''' Enter arbitrary content.<ref name="user-pw"> | |||
==Notes | * '''General/Certificates/Device Certificate'''<ref>The server certificate won't be validated</ref> Upload a device certificate to authenticate with at the authenticator. | ||
**The certificate must have it's private key aboard. A concatenated PEM-format certificate with the key appended will do. In principle.: | |||
<code type="text"> | |||
-----BEGIN CERTIFICATE----- | |||
MIICxzCCAjCgAwIBAgIBAzANBgkqhkiG9w | |||
... | |||
MVDEBAuPOHunKSoHcpxrlPJQ== | |||
-----END CERTIFICATE----- | |||
-----BEGIN RSA PRIVATE KEY----- | |||
MIICXQIBAAKBgQCX8OyuGH2lP39juhv+Tm4Qa | |||
... | |||
f9/z8tG | |||
-----END RSA PRIVATE KEY----- | |||
</code> | |||
=Notes= | |||
<references/> | <references/> |
Revision as of 11:18, 4 August 2014
Info
802.1X, Port-Based Network Control, is an IEEE standard. The standard allows LAN devices (wired network cabling![1]) 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[2][3].
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. An IP phone fulfills a supplicant's role.
- innovaphones' IP phones are configured to support pass-through of EAPOL messages. A PC attached to the PC-port of a phone may also become a supplicant and may 802.1X-authenticate independently and separately[4].
- Authenticator: The party facilitating the authentication. A switch will usually be the authenticator.
- Authentication Server: The party providing the authentication service to the authenticator. The 802.1X standard mentions a RADIUS server to be an authentication server.
- Sample Protocol Flow, EAP-MD5:
- Sample Protocol Flow, EAP-TLS:
Configuration
EAP-MD5
- User Enter the user/identity to authenticate with.
- Password Enter the shared secret for the MD5 challenge/response handshake.
EAP-TLS
- User Enter the user/identity to be sent within the EAP Identity request.[5]
- Password Enter arbitrary content.Cite error: Closing
</ref>
missing for<ref>
tag Upload a device certificate to authenticate with at the authenticator.- The certificate must have it's private key aboard. A concatenated PEM-format certificate with the key appended will do. In principle.:
BEGIN CERTIFICATE-----
MIICxzCCAjCgAwIBAgIBAzANBgkqhkiG9w
...
MVDEBAuPOHunKSoHcpxrlPJQ==
END CERTIFICATE-----
BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQCX8OyuGH2lP39juhv+Tm4Qa
...
f9/z8tG
END RSA PRIVATE KEY-----
Notes
- ↑ The standard refers to 802 LANs as a whole, including shared media such as 802.11 WLANs. However, only 802.3 LANs are targeted by the functionality discussed in this article.
- ↑ It is an authenticator's task to guarantee that non-EAPOL traffic won't be forwarded before an authentication succeeded.
- ↑ 802.1X must not be considered a bullet-proof security mechanism, since all traffic following the authentication phase is not authenticated.
- ↑ Major authenticators do support multi-host authentication
- ↑ A non-empty user/password just serves as an "on"-switch