1. 4-way handshake sequence
2. Key Heirarchy
The EAPOL encryption key is the middle 128 bits of the PTK value.
And the first 128 bits of the PTK (KCK), is used in the computation(and validation) of the EAPOL frame MIC field value (4way handshake Message 1/2).
3. EAPOL Frame format
4 Key Data Format
Key data may be zero or more InformationElement(s) (such as the RSN information element), and zero or more key dataencapsulation(s) (KDEs) (such as GTK(s)).
4.1 RSN Information
4.2 GTK
If theEncrypted Key Data subfield (of the Key Information field) is set, the entireKey Data field shall be encrypted. If the Key Data field uses the NIST AES keywrap, then the Key Data field shall be padded before encrypting if the key datalength is less than 16 octets or if it is not a multiple of 8. The paddingconsists of appending a single octet 0xdd followed by zero or more 0x00 octets.When processing a received EAPOL-Key message, the receiver shall ignore thistrailing padding. Key Data fields that are encrypted but do not containthe GroupKey or STAKey KDE, shall be accepted.
If the GroupKey or STAKey KDE is included in the Key Data field but theKey data field is not encrypted the EAPOL-Key frames shall be ignored.
5. Sample 4-way Handshake
5.1 Message 1
The Authenticator sends an EAPOL-Key frame containing an ANonce.
Key data is zero.
5.2 Message 2
The Supplicant derives a PTK from ANonce and SNonce.
The Supplicant sends an EAPOL-Key frame containing SNonce, the RSN information element
from the Association Request frame and a MIC.
MIC is the KCK (The first 128 bits in the PTK).
Key data is RSN Information.
802.1X authentication, CCMP pairwise dna group cipher suites.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
30, // information element id 14, // length 01 00, // Version 1 00 0F AC 04, // CCMP as group cipher suite 01 00, // pairwise cipher suite count 00 0F AC 04, // CCMP as pairwise cipher suite 01 00, // authentication count 00 0F AC 02, // authentication type is PSK 08 00, // PSK replay counter |
5.3 Message 3
The Authenticator derives PTK from ANonce and SNonce and validates the MIC in the EAPOL Key frame
The Authenticator sends an EAPOL-Key frame containing ANonce, the RSN from its Beacon or Probe
Response messages, MIC whether to install the temporal keys, and the encapsulated GTK
Should the MIC data be same with the one in Message 2 ?!
Key data is RSN Information + GTK, and the data is encapsulated by using of the AES algrithm with the KEK(The middle 128 bits in PTK).
5.4 Message 4
To be added.
原始链接 http://blog.csdn.net/stevenliyong/article/details/6599528