Sunday, January 8, 2012

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
(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
(Open System)
1
(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.

No comments:

Post a Comment