Key Descriptor Version in EAPOL Key Frames July 2010 doc.: IEEE 802.11-10/0856r0 July 2010 Key Descriptor Version in EAPOL Key Frames Date: 2010-07-13 Authors: Dan Harkins, Aruba Networks Dan Harkins, Aruba Networks

July 2010 doc.: IEEE 802.11-10/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

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

EAPOL Key Frame Key Descriptor Version July 2010 EAPOL Key Frame Key Descriptor Version Section 8.5.2 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 8.5.2 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

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

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

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

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

July 2010 References Dan Harkins, Aruba Networks