Port-based Network Access Control (802.1X)
IEEE 802.1X is a Port-based Network Access Control (PNAC). Despite the fact that the port is usually considered a physical interface of an access switch in local area networks (LANs), the PNAC method aka 802.1X can be efficiently utilised in local wireless networks (WLANs or Wi-Fi)…
Generally speaking, the access control is covered by the Authentication, Authorisation and Accounting (AAA) functions:
- Authentication verifies identity of the subject requesting network or service access.
- Authorisation assigns access rights (privileges) of the subject according to the authentication result and a predefined access policy.
- Accounting provides gathering of information related to the subject activity defined by the authorisation rules.
The IEEE 802.1X ensures the AAA functions using the Extensible Authentication Protocol (EAP) over IEEE 802, which is also known as the EAP over LAN (EAPoL) and which is an IETF standard defined in the RFC 3748 and updated by the RFC 5247 and RFC 7057. It is an authentication framework, which provides transport and key negotiation using authentication methods defined:
- in RFC documents – e.g. EAP-MD5, EAP-TLS, EAP-PSK,
- by manufacturers – e.g. LEAP (Cisco Systems, Inc.), or EAP-TTLS, EAP-FAST (both available as RFC documents today).
Therefore, the EAP is not a method, it rather provides a wide range of applications, such as in the Wi-Fi Protected Access (WPA and WPA2) defined in the IEEE 802.11i-2004 and IEEE 802.11-2007 standards, also referred to as EAP over Wireless (EAPoW), known from the wireless networks (Wi-Fi), mobile networks (e.g. EAP-SIM, EAP-AKA) or the IoT systems (e.g. the EAP-NOOB draft).
EAP Flexible Authentication via Secure Tunnelling
In the Microsoft Windows environment, it is efficient to utilise the EAP Flexible Authentication via Secure Tunneling (EAP-FAST) method designed by the Cisco Systems, Inc. and defined in the RFC 4764. The EAP-FAST uses a Protected Access Credential (PAC) to establish a TLS tunnel, in which client credentials are verified. The whole communication process can be simplified into three phases:
- Negotiation of a shared key between the subject (workstation) and an authenticator (access switch) using the Authenticated Diffie-Hellman Protocol (ADHP)
- Tunnel establishment based on the authentication using the PAC to provide confidentiality and integrity during the authentication process.
- Subject authentication, where the PAC can be imagined as a secure cookie, which is locally stored at the subject as a proof of successful authentication.
The EAP-FAST method enables encapsulation of multiple EAP methods, e.g. sending device credentials and user credentials in a single EAP session (a RADIUS session to be more precise, the details will be discussed later) using EAP chaining. The drawback is that Apple macOS does not support it. The EAP-FAST can be used without the PAC, which makes it a different standardised method called the EAP-TLS.
EAP Transport Layer Security
The most widely adopted and supported method by manufacturers is the EAP Transport Layer Security (EAP-TLS), which is defined in the RFC 5216. The vast majority of implementations are based on the client certificate request as per the ITU-T X.509 standard, although the standard does not explicitly request it.
The certificate usage represents a standard compromise between convenience (usability) and security, since a single compromised user account (password) cannot be used for connection into a secure environment protected by the EAP-TLS (the attacker would lack the client-side certificate). In order to accomplish maximum security, the certificate can be stored on a smart card. However, device certificates are usually stored in the Trusted Platform Module (TPM), which is defined in ISO/IEC 11889 and which is a secure cryptoprocessor that stores cryptographic keys (e.g. certificates).
Another widely used method, which was originally designed by Cisco Systems, Microsoft and RSA Security, is called the Protected EAP (PEAP). Nowadays, both versions of PEAPv1 and PEAPv2 are published as IETF drafts. This method is based on a server certificate using which is an encrypted TLS tunnel established to be further used for user identity verification (authentication) with a simultaneous verification of the server identity using its public key. Despite the fact the Microsoft is among the authors, it supports only the following two methods (used in the WPA and WPA2 standards):
- Microsoft’s Challenge Handshake Authentication Protocol (PEAPv0/EAP-MSCHAPv2) * Generic Token Card (PEAPv1/EAP-GTC).
Protected EAP Transport Layer Security
For 802.1X, it is useful to utilise the combination of PEAP with an established TLS tunnel called the Protected EAP Transport Layer Security (PEAP-TLS), when both peers get mutually authenticated using certificates (more information can be found in Microsoft’s web). The infrastructure appliances designed by Cisco designate this method as PEAP (EAP-TLS) or EAP-PEAP-TLS.
The PEAP creates a tunnel between the client and the server, which uses an X.509 certificate (similar to the TLS session between a client and a server). After the tunnel is established, one of the following (inner) EAP authentication methods can be used within the tunnel to authenticate the client:
- EAP-MSCHAPv2 defined in the RFC 2759.
- EAP-GTC defined in the RFC 3748.
- EAP-TLS; although not widely known, the PEAP can use EAP-TLS as an inner method.
Theoretically, the EAP-TLS can be used as the only method, i.e. without the outer tunnel. However, it reduces the security. The native Microsoft Windows supplicant supports authentication using a device’s and user’s certificate, yet only one at a time. Without a logged on user, the device gets authenticated. After user’s logon, user’s authentication is performed. The method chaining is theoretically possible, yet very problematic. The Cisco ISE (used as authenticator) can keep the user authentication session cached, using the so called Machine Access Restriction (MAR) cache, and use it during the user authentication phase. However, there are many issues with it during device hibernation, LAN/WLAN switching etc. (more information can be found in the Machine Access Restriction Pros and Cons document.
On the other hand, the EAP-FASTv2 performs both methods at once, which eliminates the MAR cache-related issues. Nowadays, it is the only protocol to provide such features. The EAP Tunnel Extensible Authentication Protocol (EAP-TEAP), which is defined in the RFC 7170 and which should also provide the chaining features, is not supported by either the Cisco ISE or Microsoft Windows.
MAC Authentication Bypass
The MAC Authentication Bypass (MAB) is an authentication method designed to enable access to devices, which do not support the 802.1X (the EAP to be more precise). The MAB is based on explicit declaration of exceptions, which are allowed access according to their MAC addresses. The downside is an increased management requirements when a database of up-to-date MAC addresses needs to be maintained and furthermore, the MAC can be spoofed by an adversary (such as by cloning a printer’s address). However, in order to minimise such risks, the printer’s VLAN access is usually very strictly defined and limited.
Cornerstones of the 802.1X
The EAP differentiates between the following two Port Authentication Entities (PAEs):
- Supplicant – i.e. a PAE, which requests access to network resources.
- Authenticator – i.e. a PAE, which controls access to network resources.
Together with the Authentication server, these two authentication entities represent the cornerstones of the 802.1X standard. The supplicant is usually implemented as a SW equipment of a network device (e.g. Cisco AnyConnect Secure Mobility Client, Microsoft Native Supplicant, Network Manager etc.) The authenticator is usually an access switch. The communication between the supplicant and the authenticator (the supplicant is connected to) is provided by the EAP, whereas the communication between the authenticator and the authentication server is provided by a different AAA protocol, usually the Remote Authentication Dial In User Service (RADIUS), as defined in RFC 2865, RFC 2866. The message exchange details can be found here.
Public Key Infrastructure
The EAP-FAST and EAP-TLS require robust Public Key Infrastructure (PKI), which can be provided by the Domain Controller (DC) in corporate world (Microsoft). The DC is equipped with various mechanisms to issue and revoke certificates using either the Online Certificate Status Protocol (OCSP) or the Certificate Revocation List (CRL) method.
In order to prevent the risk of certificate verification request loop, it is important to provide the OCSP and CRL services via plain HTTP, i.e. not HTTPS. Response integrity is provided using cryptographic signatures, which eliminates possible MitM attacks. Confidentiality does not make sense, as the goal is to provide the revoked certificates information details publicly available.
A list of selected issues that may occur during PNAC deployment.
Usage of Multiple Authentication Methods
When compared to other SW products, the current Microsoft Windows version (Windows 10 native supplicant) does not provide multiple EAP chaining methods.
Trusted Platform Module Issues
If the TPM is accessed and used by multiple entities (such as the Microsoft Windows applications and McAfee antivirus), the TPM integrity may get corrupted, as a result of which the stored certificates cannot be used for authentication. As a workaround, the McAfee needs to be replaced by Microsoft Defender.
Suitable Supplicant Selection
The Cisco AnyConnect proved to be a very unreliable 802.1X supplicant, as the NAM process often terminates itself without reasons, which renders the network access impossible, and it sometimes does not even recognise all network interfaces. The version tested in 2019 denied network access completely (a bug).
The MAB database needs to be effectively managed. For that purpose, the company’s asset management tool needs to contain MAC addresses of all devices to address authentication server unavailability (e.g. Cisco ISE), which represents a de facto single point of failure (SPoF).