1. Key Descriptor Version in EAPOL Key Frames
July 2010
doc.: IEEE /0856r0
July 2010
Key Descriptor Version in EAPOL Key Frames
Date:
Authors:
Dan Harkins, Aruba Networks
Dan Harkins, Aruba Networks

2. July 2010
doc.: IEEE /0856r0
July 2010
Abstract
This document discusses the processing of EAPOL Key Frames and the Key Descriptor Version.
Dan Harkins, Aruba Networks
Dan Harkins, Aruba Networks

3. EAPOL Key Frame Key Descriptor Version
July 2010
EAPOL Key Frame Key Descriptor Version
The current definition from 8.5.2:
Key Descriptor Version is 3 bits (note the error in the figure) allowing 7 distinct versions. Three have been defined already.
Dan Harkins, Aruba Networks

4. EAPOL Key Frame Key Descriptor Version
July 2010
EAPOL Key Frame Key Descriptor Version
Section b) 1) describes the values to use for the key descriptor depending on the AKM (and pairwise cipher) negotiated and the data integrity algorithm and key wrapping algorithm to use for that particular value.
Section h) describes how big the MIC field will be depending on the Key Descriptor Value. (It says, “This field is 16 octets in length when the Key Descriptor Version subfield is 1 or 2” but there are 3 versions defined and it does not actually say the MIC size for version 3– it’s also 16 octets).
Dan Harkins, Aruba Networks

5. EAPOL Key Frame Key Descriptor Version
July 2010
EAPOL Key Frame Key Descriptor Version
Version number determines processing
Value 1 indicates HMAC-MD5 for data integrity and ARC4 for key wrapping. MIC is 16 octets
Value 2 indicates HMAC-SHA1 for data integrity and AES Key Wrap (RFC 3394) for key wrapping. MIC is 16 octets.
Value 3 indicates AES-CMAC for data integrity and AES Key Wrap (RFC 3394) for key wrapping. MIC is 16 octets.
There are other options possible:
RFC 5649 version of AES Key Wrapping
HMAC-SHA256 or HMAC-SHA384
Winner of the SHA3 competition
Dan Harkins, Aruba Networks

6. EAPOL Key Frame Key Descriptor Version
July 2010
EAPOL Key Frame Key Descriptor Version
AKM (and pairwise cipher) determines version
00:0F:AC:1 or 00:0F:AC:2 with TKIP means version 1
00:0F:AC:1 or 00:0F:AC:2 with CCMP means version 2
00:0F:AC:3, 00:0F:AC:4, 00:0F:AC:5 or 00:0F:AC:6 means version 3
AKM (and pairwise cipher) determines the Key Descriptor Version and the Key Descriptor Version determines how to process the frame. Therefore AKM (and pairwise cipher) determines how to process the frame.
The Key Descriptor Version is extraneous.
Dan Harkins, Aruba Networks

7. July 2010
Proposal
Transmitter sets the Key Descriptor Version to 1, 2, or 3 depending on the AKM (and pairwise cipher) negotiated.
Receiver ignores Key Descriptor Version and processes frame according to the negotiated AKM (and pairwise cipher, if applicable).
Put AKM-to-processing mapping into single section.
Going forward:
New AKMs define data integrity algorithm, key wrapping algorithm, and size of MIC. This goes in the AKM-to-processing section
Key Descriptor Version is not set for new AKMs.
Dan Harkins, Aruba Networks

8. EAPOL Key Frame Key Descriptor Version
July 2010
EAPOL Key Frame Key Descriptor Version
Comments?
Dan Harkins, Aruba Networks

9. July 2010
References
Dan Harkins, Aruba Networks