EAP-PEAP

EAP-Protected Extensible Authentication Protocol (EAP-PEAP):

  • creates an encrypted TLS tunnel within which the supplicant’s identity is validated
  • supplicant identity/credentials are always encrypted inside the TLS tunnel
  • also referred as ‘EAP inside EAP’
  • all PEAP versions require a server-side certificate
  • all PEAP versions require two phases
  • highly secured EAP type

3 major PEAP versions:

  • EAP-PEAPv0 (EAP-MSCHAPv2):
    • from Microsoft
    • most common from of PEAP
    • protocol used for authentication inside the tunnel EAP-MSCHAPv2
    • credentials: username and password
    • server-side certificate: mandatory
    • client-side certificate: not supported
  • EAP-PEAPv0 (EAP-TLS)
    • from Microsoft
    • rarely used, because of EAP-TLS version
    • protocol used for authentication inside the tunnel EAP-TLS
    • credentials: certificate
    • server-side certificate: mandatory
    • client-side certificate: mandatory, which are validated inside the tunnel
  • EAP-PEAPv1 (EAP-GTC)
    • from Cisco
    • used with software/hardware tokens
    • protocol used for authentication inside the tunnel EAP-GTC
    • credentials: tokens like OTP, possible mix of username, password and token code
    • server-side certificate: mandatory
    • client-side certificate: optional

1.PNG

Complete process seen in frames and events in syslog on wireless controller (Extreme Wing). RADIUS server is onboard on the wireless controller.

Authentication request + response, Association request + response in frames:

2.PNG

The same events from the wireless controller’s perspective:

[AP1] 18:20:54.549: mgmt:rx auth-req from CC-44-63-1B-2D-FA on radio 1 (mgmt.c:3940)
[AP1] 18:20:54.549: mgmt:tx auth-rsp to CC-44-63-1B-2D-FA on radio 1. status: success (mgmt.c:1314)
[AP1] 18:20:54.550: mgmt:rx association-req from CC-44-63-1B-2D-FA on radio AP1:R2 signal-strength is -43dBm (mgmt.c:3921)
[AP1] 18:20:54.550: client:CHD: chd_init_mu (chd.c:541)
[AP1] 18:20:54.550: client:MU supports 802.11v bss transition CC-44-63-1B-2D-FA (mgmt.c:2762)
[AP1] 18:20:54.550: client:MU CC-44-63-1B-2D-FA panBU enab_cap=00 00 00 00, supp_cap=00 00 00 00 (mgmt.c:3128)
[AP1] 18:20:54.550: client:using cached vlan 4 for wireless client CC-44-63-1B-2D-FA (mgmt.c:3372)
[AP1] 18:20:54.550: mgmt:Client CC-44-63-1B-2D-FA negotiated WPA2-EAP on wlan (study) (mgmt.c:3449)
[AP1] 18:20:54.551: mgmt:tx association-rsp success to CC-44-63-1B-2D-FA on wlan (study) (ssid:study) with ftie 0 (mgmt.c:3535)

 

The proper authentication starts:
In Frame 310 we see Identity Request – step 4a in the diagram.

3.PNG

4.PNG

[AP1] 18:20:54.551: client:state MU_STATE_DOT1X for client CC-44-63-1B-2D-FA (mgmt.c:1218)
[AP1] 18:20:54.551: client:wireless client CC-44-63-1B-2D-FA changing state from [Init] to [802.1x/EAP Auth] (mgmt.c:630)
[AP1] 18:20:54.551: eap:sending eap-code-request code 1, type 1 to CC-44-63-1B-2D-FA (eap.c:964)
[AP1] 18:20:54.551: eap:sending eap-id-req to CC-44-63-1B-2D-FA (eap.c:991)

 

In the meantime, we see action frames: neighbor report request + response (802.11k) and add block ack request + response.

[AP1] 18:20:54.552: mgmt:rx action frame from CC-44-63-1B-2D-FA on radio 1 (mgmt.c:3956)
[AP1] 18:20:54.552: client:rx radio rrm neighbor-report request from CC-44-63-1B-2D-FA (mgmt.c:3753)
[AP1] 18:20:54.552: mgmt:Sending neighbor-report response from smart-rf records[0]:found[0], roam learned entries[0] (neighbors.c:10
[AP1] 18:20:54.552: mgmt:Sending neighbor-report response to client CC-44-63-1B-2D-FA (80211k.c:108)

 

After that in frame 320 there is Identity Response frame – step 4b in the diagram. The identity means a username, which might or might not be a real username.

5

[AP1] 18:20:54.575: eap:rx eap id-response from CC-44-63-1B-2D-FA (eap.c:697)
[AP1] 18:20:54.575: radius:aaa-policy 123 user: user mac: CC-44-63-1B-2D-FA server_is_candidate: 1 0 0 0 0 0 (radius.c:4856)
[AP1] 18:20:54.577: radius:access-req sent to wireless controller to be proxied via its adopter centralized controller (if any) to 1

Next in the capture we see control frames block ack request + response with starting of sequencing numbers.

In frame 324 now we see Start EAP-PEAP Request – step 6 in the diagram.

6

7.PNG

[AP1] 18:20:54.575: eap:rx eap id-response from CC-44-63-1B-2D-FA (eap.c:697)
[AP1] 18:20:54.575: radius:aaa-policy 123 user: user mac: CC-44-63-1B-2D-FA server_is_candidate: 1 0 0 0 0 0 (radius.c:4856)
[AP1] 18:20:54.577: radius:access-req sent to wireless controller to be proxied via its adopter centralized controller (if any) to 1

 

We see a Client Hello frame in frame 326:

8.PNG

9.PNG

In next 2 x frames (fragmented): 330 and 335 the AS responds with the Server Hello, delivers a certificate and the Server Hello Done – step 7 in the diagram.

10.PNG

Nowe we see 3 x frames: 356, 358, 361 related to establishing a secure TLS tunnel between the supplicant and the AS – step 8 in the diagram.

11.PNG

12.PNG

13.PNG

14

Now we see encrypted data exchange inside the TLS tunnel between the supplicant and the AS – steps 9-14 in the diagram.
The AS requests the real username and sends an EAP-MSCHAPv2 challenge request to the supplicant. The supplicant will reply with the hashed challenge response. Eventually the AS verifies if the credentials are okay or not and sends it to the supplicant, which ACK it.

15.PNG

Each application data log will be like in wireless controllers:

[AP1] 18:20:56.771: eap:rx eap pkt from CC-44-63-1B-2D-FA (eap.c:720)
[AP1] 18:20:56.774: radius:access-req sent to wireless controller to be proxied via its adopter centralized controller (if any) to 1
[AP1] 18:20:56.780: radius:RAD_MSG_AUTHENTICATOR (radius.c:1181)
[AP1] 18:20:56.781: radius:rx access-challenge from radius server for CC-44-63-1B-2D-FA (radius.c:3870)
[AP1] 18:20:56.781: eap:sending eap-code-request code 1, type 25 to CC-44-63-1B-2D-FA (eap.c:964)
[AP1] 18:20:56.781: eap:sending eap-req [eap_type:25(peap)] to CC-44-63-1B-2D-FA (eap.c:999)

Finally in frame 380 the EAP-Success frame is sent (alternatively EAP-Failure) – step 17 in the diagram. The TLS tunnel is torn down.

16.PNG

[AP1] 18:20:56.880: eap:sending eap-success to CC-44-63-1B-2D-FA (eap.c:1007)
[AP1] 18:20:56.880: client:802.1x authentication success for client CC-44-63-1B-2D-FA (eap.c:1140)

 

As now Master Session Key (MSK) is known to the authenticator and the AS and the Pairwise Master Key (PMK) is derived and known by the authenticator and the supplicant. The 4-Way Handshake starts to create an unique, dynamic keys for the session – steps 18-21 in the diagram.

17.PNG

[AP1] 18:20:56.880: client:starting WPA2-CCMP keying for client CC-44-63-1B-2D-FA (eap.c:1216)
[AP1] 18:20:56.880: client:wireless client CC-44-63-1B-2D-FA changing state from [802.1x/EAP Auth] to [802.11i Keying] (mgmt.c:630)
[AP1] 18:20:56.881: wpa-wpa2:tx msg #1 to CC-44-63-1B-2D-FA attempt: 1 (80211i.c:619)
[AP1] 18:20:56.886: wpa-wpa2:rx msg #2 from mu CC-44-63-1B-2D-FA (80211i.c:1166)
[AP1] 18:20:56.887: wpa-wpa2:tx msg #3 to CC-44-63-1B-2D-FA attempt: 1 (80211i.c:893)
[AP1] 18:20:56.889: wpa-wpa2:rx msg #4. WPA2-AES handshake done. CC-44-63-1B-2D-FA DATA-READY (80211i.c:1150)
[AP1] 18:20:56.891: client:wireless client CC-44-63-1B-2D-FA changing state from [802.11i Keying] to [Data-Ready] (mgmt.c:630)

Since now the supplicant can send data or QoS data frames – step 22 in the diagram.

Reference:
CWAP Official Study Guide: Exam PW0-270 – Chapter 4
My lab

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s