An Example of Security for 802.11

The client passes through a number of phases when associating to a Wi-Fi network that uses enterprise-grade security. To help understand how everything fits together, we will go through one example authentication, using WPA2 and the EAP method EAP-PEAP, which requires each mobile device to have a username and password. The password will be sent, securely tunneled through PEAP, to the RADIUS server, which is usually attached to a Microsoft Active Directory server.

Each message that is sent will be represented by a table, showing the relevant contents of the message. The aim is to allow the reader to follow along, when analyzing wireless packet capture traces, what the individual steps mean, when a client associates to the network. As a matter of presentation, when information that might be important is repeated in subsequent messages, it will be omitted for those messages.

Step 1: Associate with the Wi-Fi Network

The mobile device, having scanned for the SSID of the network desired—let's call it voice for this example—has found an access point that is advertising the voice SSID.

The client requests a connection with the access point by sending an 802.11 Authentication message, requesting open authentication, meaning that the client does not want to use WEP. See Table 1.

Table 1: 802.11 Authentication message from client to AP 

Frame Control	Destination Address	Source Address	BSSID	Algorithm Number	Authentication Sequence
Authentication	AP Address	Client Address	AP Address	0 (Open System)	1

The access point accepts the open connection by responding with its own 802.11 Authentication message, to the client, simply stating that the request is a success. See Table 2.

Table 2: 802.11 Authentication message from AP to client 

Frame Control	Destination Address	Source Address	BSSID	Algorithm Number	Authentication Sequence	Status Code
Authentication	Client Address	AP Address	Client Address	0 (Open System)	1	0 (Success)

The client then sends an 802.11 Association Request message to the access point, informing the access point of its Wi-Fi capabilities, supported extensions and 802.11 features (Table 3).

Table 3: 802.11 Association request message from client to AP 

Frame Control	Destination Address	Source Address	BSSID	Capabilities	SSID	Information Elements
Association Request	AP Address	Client Address	AP Address	Capabilities	voice	Radio, Security, and QoS Capabilities

The access point accepts the association request and sends an 802.11 Association Response message to the client, announcing success, providing the client with the access point's capabilities and its network-wide configuration parameters.

At this point, the client cannot speak to any other access point without disconnecting or being disconnected, but it cannot send or receive any real data traffic. The client must first use EAPOL to authenticate.

Step 2: Authenticate with the AAA Server

The sends an EAPOL Start message (Table 4), encoded as a Wi-Fi Data frame with Ethernet protocol 0×888E, sent to the Ethernet address of the access point. This message is optional, but when sent is meant to request that the access point should start the EAP exchange.

Table 4: 802.11 EAPOL start message 

Frame Control	Destination Address	Source Address	BSSID	Ether Type	EAPOL Type
Data	AP Address	Client Address	AP Address	0×888E	Start

At around the same time, the access point will usually voluntarily send an EAPOL message with an EAP Request Identity message inside (Table 5), triggering the start of the authentication process. The Request Identity message is the EAP way of asking the client to announce who he or she is.

Table 5: 802.11 EAP request identity 

Destination Address	Source Address	Ether-type	EAPOL Type	EAP Code	EAP Type	Identity
Client Address	AP Address	0×888E	0=EAP	1=Request	1=ldentity	hello

The client receives the request for the identity and responds with identity to use (Table 6). Let's call the user "user", in the domain "LOCATION". PEAP uses a separate protocol (MSCHAPv2) for the presentation of the real username and password. The identity given in the outer protocol may or may not matter, depending on the RADIUS server. In this example, the outer identity is the same one given as the real, inner identity: "LOCATION user".

Table 6: 802.11 EAP response identity 

Destination Address	Source Address	Ether-type	EAPOL Type	EAP Code	EAP Type	Identity
AP Address	Client Address	0×888E	EAP	2=Response	Identity	LOCATION user

This response triggers the start of the PEAP protocol, tunneled over EAP, tunneled over EAPOL, carried over 802.11. The first message is from the RADIUS server, through the access point, and informs the client that PEAP is beginning (Table 7).

Table 7: 802.11 EAP request PEAP 

Destination Address	Source Address	Ether-type	EAPOL Type	EAP Code	EAP Type	Flags
Client Address	AP Address	0×888E	EAP	Request	25=PEAP	Start

PEAP uses TLS as the outer tunnel, within which the encrypted username and password are passed. The first message in the TLS exchange is what is known as a TLS Client Hello (Table 8). The Client Hello passes the client's nonce, used as a part of the key derivation protocol. The client will specify a number of cipher suites, but must specify RSA public key encryption with RC4 stream encryption and either MD5 or SHA hashes.

Table 8: 802.11 PEAP client hello 

Destination Address	Source Address	EAP Code	EAP Type	TLS Type	Handshake Type	Nonce	Cipher Suites
AP Address	Client Address	Response	PEAP	22=Handshake	1=Client Hello	random	Many

The server will respond with a Server Hello. The Server Hello message will specify the server's nonce, a session ID (which is usually not taken advantage of by wireless clients), one of the client's cipher suite to use for the rest of the process, and the beginning of a chain of certificates for the RADIUS server, which identifies itself as being valid. The client will usually verify that the server is signed by a valid certificate authority somewhere along the path and is allowed to serve the role it does, unless the client's administrator has explicitly disabled this check. Because certificates are much longer than the maximum EAPOL packet, the PEAP Server Hello and Certificate will be divided up over many consecutive EAPOL frames from the access point. After the certificate, the server may include a request for the client to send a certificate. This would be used by PEAP to short-circuit the inner tunnel and revert to plain TLS, if the client has a certificate. Usually, PEAP is not used with client certificates, so the client will ignore this request and trigger the password exchange. If requested, the types of certificates and distinguished names of acceptable certificate authorities, one of whom needed to have signed any client certificate given, will be provided. The message ends with a Server Hello Done. See Table 9.

---

Table9: 802.11 PEAP server hello and certificate, usually split across multiple EAPOL message

---

The client will respond to the intermediate server certificate messages with empty responses, to keep the request/response protocol going (Table 10).

Table 10: 802.11 EAP response PEAP 

Destination Address	Source Address	Ether-type	EAPOL Type	EAP Code	EAP Type
AP Address	Client Address	0×888E	EAP	Response	PEAP

When the Server Hello Done message arrives at the client, the client will kick off the second, inner phase of PEAP. First, the client responds with a Certificate handshake message. If the client were going to provide a certificate, it would do so here. However, with normal PEAP, the certificate message will be empty. Following this is the Client Key Exchange. Let's assume that the server and client agreed to RSA public key encryption. The client chooses a random 48-byte premaster key, which is encrypted by the server certificate's RSA public key, and then packaged in the key field. Following this comes the Change Cipher Spec message (Table 11), to inform the server that all future communications will take place using encryption based on the key. Finally, the first encrypted message is introduced, which is a marker, encrypted by the key, that states that the cipher change is done.

---

Table 11: 802.11 PEAP client change cipher spec

---

The server now responds with a Change Cipher Spec and Finished message (Table 12), to mark the switch over of the protocol completely to the inner TLS tunnel.

Table 12: 802.11 PEAP server change cipher spec 

Destination Address	Source Address	EAP Code	TLS Type	Handshake Type	Handshake Type	Encrypted Handshake
Client	AP Address	Request	Handshake	Change Cipher Spec	Encrypted Handshake Message	Finished (encrypted with TLS PRF)

The client, once again, sends an empty response (Table 13).

Table 13: 802.11 EAP response PEAP 

Destination Address	Source Address	Ether-type	EAPOL Type	EAP Code	EAP Type
AP Address	Client Address	0×888E	EAP	Response	PEAP

Now, the inner MSCHAPv2 protocol can take place. Table 14 will peel back the inner TLS tunnel and reveal the contents. The inner tunnel will also present an EAP exchange, but using MSCHAPv2, rather than TLS.

Table 14: 802.11 PEAP encrypted request identity 

Destination Address	Source Address	EAP Code	TLS Type	EAP Code (encrypted with RC4)	EAP Type (encrypted)
Client Address	AP Address	Request	23=Application Data	Request	Identity

The first step of MSCHAPv2 is for the server to request the identity of the client.

The next step is for the client to respond, in an encrypted form, with the real identity of the user (Table 15). If the previous, outer response had been something arbitrary, the server will find out about the real username this way.

Table 15: 802.11 PEAP encrypted response identity 

Destination Address	Source Address	EAP Code	TLS Type	EAP Code (encrypted)	EAP Type (encrypted)	Identity (encrypted)
Client Address	AP Address	Response	Application Data	Response	Identity	LOCATION\ user

The server then responds with a challenge (Table 16). The challenge is a 16-byte random string, which the client will use to prove its identity.

Table 16: 802.11 PEAP encrypted MSCHAPv2 challenge 

Destination Address	Source Address	EAP Code	TLS Type	EAP Code (encrypted)	EAP Type (encrypted)	CHAP Code (encrypted)	Challenge (encrypted)
Client Address	AP Address	Response	Application Data	Request	MSCHAPv2	Challenge	random

The client responds to the challenge. First, it provides a 16-byte random challenge of its own. This is used, along with the server challenge, the username, and the password, to provide an NT response (Table 17).

Table 17: 802.11 PEAP encrypted MSCHAPv2 response 

Destination Address	Source Address	EAP Code	TLS Type	EAP Code (encrypted)	CHAP Code (encrypted)	Peer Challenge (encrypted)	Response (encrypted)
AP Address	Client Address	Response	Application Data	Response	Response	random	NT response

Assuming the password matches, the server will respond with an MSCHAPv2 Success message (Table 18). The success message includes some text messages which are intended to be user printable, but really are not.

Table 18: 802.11 PEAP encrypted MSCHAPv2 server success 

Destination Address	Source Address	EAP Code	TLS Type	EAP Code(encrypted)	CHAP Code(encrypted)	Authenticator Message(encrypted)	Success Message(encrypted)
Client Address	AP Address	Request	Application Data	Request	Success

The client now responds with a success message of its own (Table 19).

Table 19: 802.11 PEAP encrypted MSCHAPv2 client success 

Destination Address	Source Address	EAP Code	TLS Type	EAP Code (encrypted)	CHAP Code (encrypted)
AP Address	Client Address	Response	Application Data	Response	Success

The server sends out an EAP TLV message now, still encrypted, indicating success (Table 20). The exchange exists to allow extensions to PEAP to be exchanged in the encrypted tunnel (such as a concept called cryptobinding, but we will not explore the concept further here).

Table 20: 802.11 PEAP encrypted MSCHAPv2 server TLV 

Destination Address	Source Address	EAP Code	TLS Type	EAP Code (encrypted)	TLV Result (encrypted)
Client Address	AP Address	Request	Application Data	33=TLV	Success

The client sends out an EAP TLV message of its own, finishing up the operation within the tunnel (Table 21).

Table 21: 802.11 PEAP encrypted MSCHAPv2 server TLV 

Destination Address	Source Address	EAP Code	TLS Type	EAP Code (encrypted)	TLV Result (encrypted)
AP Address	Client Address	Response	Application Data	TLV	Success

Now, the server sends the RADIUS Accept message to the authenticator. This message includes the RADIUS master key, derived from the premaster key that the client chose. This key is sent to the authenticator, where it becomes the PMK for WPA2 or the input to the PMK-R0 for 802. 11r. The authenticator then generates an EAP Success message (Table 22), which is sent over the air to the client.

Table 22: 802.11 EAP success 

Destination Address	Source Address	EAP Code
Client Address	AP Address	3=Success

The sheer number of packets exchanged in this 802.1X step is what leads to the need for key caching for mobile clients in Wi-Fi, and also eliminates the need to perform the 802.1X negotiation except on the first login of the client.

Step 3: Perform the Four-Way Handshake

Both the authenticator and the client have the PMK. The four-way handshake derives the PTK. The first message (Table 23) sends the authenticator's nonce, and a copy of the access point's RSN information.

Table 23: 802.11 Four-way handshake message one 

Destination Address	Source Address	EAPOL Type	Key Type	Flags	Nonce	RSN IE
Client Address	AP Address	Key	RSN (WPA2)	Ack	random	Same as in Beacon

The client generates the PTK, and sends the next message (Table 24), with its nonce and a copy of the client's RSN information, along with a MIC signature.

Table 24: Four-way handshake message two 

Destination Address	Source Address	EAPOL Type	Flags	Nonce	MIC	RSN IE
AP Address	Client Address	Key	MIC	random	hash	Same as in Association

The third message, also with a MIC, delivers the GTK that the authenticator is currently using for the BSS, encrypted (Table 25).

Table 25: 802.11 Four-way handshake message three 

Destination Address	Source Address	EAPOL Type	Flags	MIC	GTK
Client Address	AP Address	Key	Install, Ack, MIC	hash	encrypted

Finally, the client responds with the fourth message (Table 26), which confirms the key installation.

Table 26: 802.11 Four-way handshake message four 

Destination Address	Source Address	EAPOL Type	Flags	MIC
AP Address	Client Address	Key	Ack, MIC	hash

Finally, the client is associated to the access point, and both sides are encrypting and decrypting traffic using the keys that came out of the 802.1X and WPA2 process.