Welcome To WLAN Testing : How EAP-TLS Works

EAP-TLS

Extensible Authentication Protocol – Transport Layer Security which is defined in RFC 5216 required both client and server certificates for authentication. It is one of the strongest secure EAP method since both client and server are mutually authenticated with certificates.

Before starting EAP- TLS packet flow, we need to understand required certificates for the client and server to authenticate.

Assume CA-client issues the client (personal) certificate to the client, and CA-server issues the server certificate to the server. If the server want to authenticate client, the server will verify the client's digital signature in client certificate with the public key of CA-client. Similarly client will do the same.
For Server and Client authentication, server side requires

Server certificate issued to the server by CA-server
Server's private key
CA certificate of CA-client

and the client side requires

Client (personal) certificate issued to the client by CA-client
Client's private key
CA certificate of CA-server

Below is EAP-TLS Process (Image from CWSP study guide)

1. An optional "EAPOL-Start" frame sent from the client to the Access Point to trigger EAP authentication.

2. Access point sends "EAP Request, Identity" message to the client. There is an "EAP Response, Identity" message from the client to Access Point. Identity is the username configured in client. Access Point forward this EAP response to Radius server as Access Request.

EAP-Request, Identity

EAP-Response, Identity

3. Radius server sends Access-Challenge to Access Point with EAP type. Now Access point forward as EAP Packet Request to the client. Here check value of Type is "13" for EAP-TLS in Extensible Authentication Protocol and the start bit is set to "True".

NOTE: If EAP Request type value other than 13 and start bit set, then the client will respond with Legacy NAK and tells to Access Point that the desired auth type as EAP-TLS (13)

4) Once desired EAP-Type is confirmed, client sends "Client Hello" to Access point. This is forwarded to Radius server.
"Client Hello" message lists cryptographic information such as the TLS version, the CipherSuites, data compression methods supported by the client. This message also contains a random byte string that is used in subsequent computations and session ID.

5) Radius server responds with "Server Hello, Certificate, Certificate Request, Server Hello done" to the "Client Hello".
Server chose the CipherSuite from the list provided by the client in "Client Hello", the session ID, and another random byte string. The server also sends its digital certificate. If the server requires a client digital certificate for authentication, it sends a "Certificate Request" which includes a list of the types of certificates supported and the Distinguished Names of acceptable Certification Authorities (CAs).

6) Client sends "Certificate, Client Key Exchange, Certificate verify, Change cipher spec, Encrypted Handshake message" to Access point. This is forwarded to Radius server.
If the server asks "client certificate request", the client sends a random byte string encrypted with the client's private key, together with the client's digital certificate.
Client sends the random byte string which is encrypted with the server's public key that enables both the client and the server to compute the secret key to be used for encrypting subsequent message data.
Also client verifies the server's digital certificate signature with server's CA public key.

7) Radius server responds with "Change Cipher Spec, Encrypted Handshake" in response to the "Certificate, Client key exchange, Certificate verify, Change Cipher Spec, Encrypted Handshake".