Understanding the TLS Handshake using Wireshark – EAP-TLS

By admin802.1X - ISE, 9800 Certificate, openssl, PKI, SSL

Theory

EAP-TLS (Extensible Authentication Protocol-Transport Layer Security) is an 802.1X authentication method widely used in enterprise wireless and wired networks for secure access control. It leverages the TLS protocol, which secures HTTPS, to establish mutual authentication between a client (such as a user’s device) and an authentication server (like Cisco ISE or a RADIUS server). Here’s how EAP-TLS works within the 802.1X framework and its relationship with TLS:

Key Components:

  1. Supplicant: The client device (like a laptop or smartphone) that initiates the authentication.
  2. Authenticator: The network device (such as a switch or wireless access point) that serves as a gateway and enforces access control.
  3. Authentication Server: Typically, a RADIUS server validates client credentials (certificates in EAP-TLS) and communicates with the authenticator.

How EAP-TLS Works in 802.1X:

  1. Initialization:
    • When a user device connects to the network, the authenticator (e.g., access point) initiates the 802.1X process by prompting the device to authenticate.
  2. TLS Handshake and Mutual Authentication:
    • Using the EAP-TLS method, the authentication server and the client start a TLS handshake. In EAP-TLS, the client and server present digital certificates to verify their identities.
    • The client and server exchange public keys embedded within their certificates, which are validated by each other’s trusted Certificate Authorities (CAs).
    • If either certificate fails validation, the authentication is denied, securing the network against untrusted devices.
  3. Session Key Generation:
    • Once both parties are authenticated, the TLS protocol generates a session key. This key encrypts further communications, preventing eavesdropping or tampering.
    • The session key is shared securely between the client and the server during the TLS handshake.
  4. Secured Access:
    • After successful authentication and key exchange, the authenticator opens network access for the client. This process ensures that only authenticated devices can access the network.

Role of TLS in EAP-TLS:

  • Encryption: TLS provides encryption, ensuring that sensitive authentication data (like client certificates) are transmitted securely.
  • Integrity: TLS ensures the integrity of communication by using certificates and a handshake process, protecting against spoofing or man-in-the-middle attacks.
  • Mutual Authentication: TLS allows both the client and server to authenticate each other with certificates, providing high security. This mutual authentication is crucial in environments where access control and data security are top priorities.

Benefits of EAP-TLS 802.1X:

  • Robust Security: EAP-TLS is one of the most secure EAP methods because it uses certificate-based authentication and encryption via TLS.
  • Mutual Authentication: The client and server verify each other, reducing the risk of unauthorized access.
  • Resistant to Credential-Based Attacks: Since EAP-TLS doesn’t use passwords (it uses certificates), it’s immune to password-based attacks, such as brute-force attacks.

In summary, EAP-TLS over 802.1X leverages TLS’s security strengths, providing robust mutual authentication and encryption for network access. It’s particularly popular in enterprise environments where certificate-based security, strong access control, and data protection are essential.

Practical

This lab focuses on reviewing each of the steps described above.

Does the client have a certificate? Yes or No?

Is the certificate valid? Yes or No?

Is there an 802.1X WLAN configured to support the connection request?

Is there an 802.1X authentication and authorization (RADIUS) policy to support the connection request?

Review the EAP-TLS connection via Wireshark.

An EAPOL-Start message is the first message in the 802.1X authentication process sent by a client (the supplicant) to initiate the authentication process on a network. Here’s how it works and its purpose:

EAPOL stands for Extensible Authentication Protocol over LAN. It is a protocol used by the 802.1X standard to transport authentication messages between the client, the authenticator (e.g., switch or access point), and the authentication server (e.g., the RADIUS server).

When the client device first connects to the network, it sends the EAPOL-Start message, which essentially signals the authenticator to begin the 802.1X authentication process.

By sending this message, the client indicates that it’s ready to authenticate and requests that the authentication exchange be started.

EAP-Request/Identity is an 802.1X message sent by the authenticator (e.g., a network switch or access point) to a client (supplicant) as part of the EAP (Extensible Authentication Protocol) exchange. This message requests that the client identify itself before the actual authentication process begins.

EAP-Response/Identity is the message a client (supplicant) sends in response to an EAP-Request/Identity message from the authenticator in the 802.1X authentication process. This response contains the client’s identity information, such as a username or device identifier, and is an essential part of establishing the client’s access rights.

EAP-Request/Method (such as EAP-TLS, EAP-PEAP, EAP-FAST):

After receiving the client’s identity, the RADIUS server sends an EAP-Request specifying the chosen EAP method (e.g., EAP-TLS for certificate-based authentication or EAP-PEAP for username/password). This message indicates to the client which authentication type the server expects and instructs it to proceed accordingly.

A Response-Legacy NAK (Negative Acknowledgment) is an EAP (Extensible Authentication Protocol) message sent by a client (supplicant) to inform the authenticator that it does not support or cannot use the EAP method requested by the server. This response is typically sent when the server proposes an EAP method the client does not recognize, lacks the required credentials, or cannot proceed due to policy restrictions.

The Client Hello is the first message the client (supplicant) sends as it initiates the TLS handshake.

In the EAP-TLS authentication process, the Server Hello, Certificate, and Server Hello Done messages are part of the TLS handshake initiated in response to the Client Hello message. The server sends these messages to set up the parameters for a secure communication channel and provide the server’s credentials to authenticate its identity to the client.

After the Server Hello, the server sends a Certificate message containing its digital certificate(s). The certificate is critical for proving the server’s identity and is signed by a trusted Certificate Authority (CA).

  • Server Authentication: The certificate contains the server’s public key and is verified by the client to ensure the server’s legitimacy.
  • Public Key Exchange: The server’s certificate includes its public key, which the client will use later in the key exchange to establish a secure session key.

Certificate Request Fields

The Certificate Request message includes several fields that define the criteria and requirements for the client’s certificate:

Certificate Types:

This field lists the types of certificates the server can accept, helping guide the client to select an appropriate certificate from its available options.

Depending on the cryptographic algorithms supported, common certificate types include RSA Sign, DSA Sign, and ECDSA Sign.

Supported Signature Algorithms:

Specifies the acceptable signature and hashing algorithms the server can verify, such as RSA-SHA256 or ECDSA-SHA384.

This helps ensure the client certificate uses a compatible signature format for server validation.

Distinguished Names:

The server may include a list of acceptable Distinguished Names (DNs), typically representing the certificate authorities (CAs) the server trusts.

The client checks these DNs to see if it has a certificate signed by one of the specified trusted CAs.

In the EAP-TLS (Extensible Authentication Protocol-Transport Layer Security) handshake, after the server sends its Certificate Request and the client responds with its certificate, the following messages are exchanged to complete the mutual authentication and establish a secure session. Here’s a breakdown of each message: Certificate Client Key Exchange, Certificate Verify, and Change Cipher Spec.

After the server verifies the client’s certificate, the client sends a Client Key Exchange message. This message is crucial in establishing a shared secret between the client and server.

  • Purpose:
    • The Client Key Exchange contains a pre-master secret, which both parties use to derive the session keys for encryption. The client encrypts this pre-master secret with the server’s public key (obtained from the server’s certificate) before sending it to the server.
  • Key Derivation:
    • Both the client and server use this pre-master secret and their respective random values exchanged during the handshake to generate the master secret and subsequent session keys. These keys will be used to encrypt the data exchanged during the session.

After sending the Client Key Exchange, the client sends a Certificate Verify message to prove that it possesses the private key corresponding to the public key in its certificate.

  • Purpose:
    • This message is a digitally signed hash of all the handshake messages exchanged so far, ensuring that the client can demonstrate ownership of the private key associated with its certificate.
  • Verification:
    • The server uses the client’s public key (from the client’s certificate) to verify this signature. If the verification is successful, it confirms that the client is legitimate and has completed the authentication process.

In EAP-TLS authentication and 802.1X, the EAP-Success message and the 4-Way Handshake are critical components in establishing a secure connection between the client and the network. Here’s an explanation of each part:

EAP-Success

  • EAP-Success is a message the RADIUS server sends to the client (supplicant) after successful authentication.
  • Purpose: It indicates that the client has been authenticated and can now access the network.
  • Transition: Upon receiving the EAP-Success message, the client can proceed with the following steps to establish a secure connection to the network, typically involving the 4-Way Handshake in the case of WPA2/WPA3 (Wi-Fi Protected Access).

4-Way Handshake

The 4-Way Handshake is a mechanism used in WPA2/WPA3 wireless security protocols to confirm that both the client and the access point (AP) have the correct session keys and to establish a secure connection. This process occurs after the client receives the EAP-Success message. Here’s a breakdown of the 4-Way Handshake steps:

  1. Message 1: AP to Client (ANonce):
    • The access point (AP) generates a random number known as an ANonce (Access Point Nonce) and sends it to the client. This nonce ensures that the session keys generated are unique to the session.
  2. Message 2: Client to AP (SNonce + Mic):
    • Upon receiving the ANonce, the client generates its random number called a SNonce (Supplicant Nonce) and combines it with the ANonce to derive the Pairwise Master Key (PMK).
    • The client then computes the session keys based on the PMK and sends a message to the AP containing the SNonce and a Message Integrity Code (MIC) to confirm the authenticity of the message.
  3. Message 3: AP to Client (Group Key):
    • The AP receives the client’s message, verifies the MIC, and generates session keys based on the PMK and both nonces.
    • The AP then sends a message back to the client that includes the group key (for multicast/broadcast traffic) and another MIC to verify its authenticity.
  4. Message 4: Client to AP (Ack):
    • Finally, the client acknowledges the receipt of the group key and the session keys by sending a final acknowledgment message to the AP. This message includes a MIC for additional verification.

Purpose and Security of the 4-Way Handshake

The 4-Way Handshake serves several important purposes:

  • Key Derivation: It ensures that both the client and the AP derive the duplicate session keys from the PMK and nonces, which are used for encrypting data during the session.
  • Replay Protection: Using nonces helps protect against replay attacks, where an attacker might capture and resend previous messages.
  • Integrity and Authentication: Including Message Integrity Codes (MIC) in each message verifies the sender’s authenticity and ensures that the messages have not been tampered with.

The high-level 4-way handshake can be found here.

Verification on the RADIUS server (Cisco ISE)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.