Forum

CWSP books says that RSN information element will be in EAPOL-Key2 & EAPOL-Key3 ?but I never found RSN info in EAPOL-Key3......What is realty?.Please educate me.

Other frames which has RSN information element field
1) Beacon management frames,
2) Probe response frames,
3) Association request frames,
4) Re-association request frames

Could you please provide the page number from the CWSP book ?

Thanks.

I'd also like to know the reference.

EAPOL-Key frames in the 4-way handshake are data frames (802.11 type), not management frames. The RSN IE is only found in management frames, and I'm pretty sure the RSN IE is not in any of the EAPOL frames. You might find some WPA information in the payload, but not in the MAC header, which is where the RSN IE would be found.

CWSP@Page Number:199

Line Number 19 says...The supplicant also sends its RSN information element capabilities to the authenticator and message integrity code (MIC)?.

Line numbers 25 & 26 say....The authenticator sends an EAPOL-KEY frame to the supplicant containing the ANonse, the authenticator's RSN information element capabilities and a MIC?.

(Same thing is also mentioned in CWAP page numbers 335 & 336)

I can see RSN info in EAPOL-Key2.Kindly see below and advice me.

802.1x Authentication
Protocol Version: 1
Packet Type: 3 EAPOL - Key
Body Length: 135
EAPOL - Key
Type: 2 RSN key descriptor
Key Information: %0000000100001010
xxx..... ........ Reserved
...0.... ........ Key Data Not Encrypted
....0... ........ No Request to initiate Handshake
.....0.. ........ No Error
......0. ........ Not Secure
.......1 ........ Message contains Key MIC
........ 0....... No Key ACK
........ .0...... Install: 802.1X component shall not configure the temporal key
........ ..xx.... Reserved
........ ....1... Key Type: Pairwise Key
........ .....010 Vers: HMAC-SHA1-128 is the EAPOL-Key MIC / NIST AES key wrap is the EAPOL-key enc algorithm

Key Length: 16
Replay Counter: 0
Key nOnce: 0x93D508512928BED6B99CD59FE4451EFED9E1B641D38AC0D166399CFEE0899471
EAPOL-Key IV: 0x00000000000000000000000000000000
Key RSC: 0x0000000000000000
Reserved: 0x0000000000000000
Key MIC: 0xB15A374A8CE4992BF1D0BDE6DED4DDA5
Key Data Len: 40
RSN Information <----------------------------------------------------------
Element ID: 48 RSN Information
Length: 38
Version: 1
Group Cipher OUI: 0x00-0x0F-0xAC
Group Cipher Type: 4 CCMP - default in an RSN
Pairwise Cipher Count:1
PairwiseKey Cipher List
Pairwise Cipher OUI: 0x00-0x0F-0xAC-0x04 CCMP - default in an RSN

AuthKey Mngmnt Count: 1
AuthKey Mngmnt Suite List
AKMP Suite OUI: 0x00-0x0F-0xAC-0x01 802.1X Authentication

RSN Capabilities: %0000000000010100
xxxxxxxx x....... Reserved
........ ..01.... GTKSA Replay Ctr: 1 - 2 replay counters
........ ....01.. PTKSA Replay Ctr: 1 - 2 replay counters
........ ......0. Does not Support No Pairwise
........ .......0 Does Not Support Pre-Authentication

PMKID Count: 1
PMKID: 0x187B0D6224A339E5AC69B7FD787CF370

looking for any expert advice.thx

Refer Section 8.5.3 (4 Way Handshake) of IEEE 802.11-2007 Standard.

My mistake in my earlier post. I was looking at the wrong capture and then made a wrong conclusion. Facepalm-to-self.

In the EAPOL-Key frame, you'll see that there's a 2-octet section called "Key Information." This key information is included in the frame you posted earlier. One of the fields within these 2 octets is a single bit field called the "Encrypted Key Data" field. This field indicates whether the Key Data field is encrypted or not. You'll notice that in the frame you posted, this field is set to 0, meaning not encrypted.

However, in a 4-Way handshake exchange, the third frame also contains a GTK sent by the AP to the client. The GTK is part of the key data field along with the RSN IE, and when the GTK is present, it is encrypted. So, if you take a look at the third EAPOL-Key frame in the 4-way handshake, you'll see that the "Encrypted Key Data" field will be set to 1, the Key Data length field will be a higher integer than from EAPOL-Key frame 2 (to account for the addition of a GTK), and the protocol analyzer will not attempt to decode the Key Data field because it is encrypted. The client station receiving this field can decrypt it, but we can't.

The study guide is correct on this point, but does not mention the finer points about encryption.