doc.: r Submission March 2006 AllSlide 1 A method to refresh the keys hierarchy periodically Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at. Date: Authors:

doc.: r Submission March 2006 AllSlide 2 Abstract During the Authentication, if any key in the hierarchy is compromised then all of the lower keys which are deriving form it will be compromised and their resulting sessions must be deleted. Furthermore, since the key hierarchy lacks freshness, they must never be derived again from higher layer keys. If this happened, STA may reauthenticate with the Authenticaion server. This may introduce delay. Otherwise the STA couldn’t communicate data with the AP, this will cause packet loss. It proposes a method to refresh the key hierarchy periodically to avoid the key being compromised, thus it needn’t re-authenticate.

doc.: r Submission March 2006 AllSlide 3 Background Figure 121A- Fast BSS Transition Key Hierarchy Key Hierarchy

doc.: r Submission March 2006 AllSlide 4 As different entities, whether physical or logical, may hold keying material used to derive PTKs, the four level key hierarchy is enforced to ensure that compromise of such keying material is isolated to only that branch of the hierarchy. For example, the AAA server on which the top level key is established will be able to derive the keys used by every AP in the hierarchy, and have the knowledge to decrypt any session on any AP. Thus, if the AAA server is compromised, then every key in the hierarchy is compromised and their resulting sessions must be deleted. However, if the second level is compromised (R1KH in Figure 121A), only its corresponding key PMK-R1 and the keys derived from that PMK-R1 are compromised; only the sessions on APs using the keys derived from that PMK- R1 are compromised and must be deleted. Furthermore, since the key hierarchy lacks freshness, they must never be derived again from higher layer keys. For ease of implementation, APs may delete the higher layer keys to simplify its session states.121A The mechanisms for ensuring keys are deleted and not derived again after a compromise in the key hierarchy is outside the scope of this specification. However, to ensure that keys are not deleted without warrant, there should be some mechanism to ensure authorization for key distribution as well as key deletion.

doc.: r Submission March 2006 AllSlide 5 If any key of the key hierarchy is compromised, the lower keys derived from it will all be compromised, as a result, the sessions on APs will be deleted. If this is happened, STA will reauthenticate with the Authentication server. This will take much time, and will introduce delay of course. Furthermore STA couldn’t communicate with APs during this time, this will cause packets loss. This document proposes a method to solve this problem.

doc.: r Submission March 2006 AllSlide 6 Key deriving function In the r draft, the FBT key hierarchy derives its keys using a new Key Derivation Function (KDF) as defined below: PMK-R0 = KDF-256(XXXKey, "R0 Key Derivation", SSID || MDID || R0KH-ID || 0x00 || SPA) –MSK is the Master Session Key from the 802.1X EAP authentication. –"R0 Key Derivation" is the literal string consisting of the sequence of letters 'R', '0', ' ', 'K', 'e', 'y', ' ', 'D', 'e', 'r', 'i', 'v', 'a', 't', 'i', 'o', and 'n' (no null terminator). –SSID is the service set identifier. –R0KH-ID is the 16-octet identifier of the holder of PMK-R0. –SPA is the STA's MAC address. PMKR0Name=Truncate-128(SHA-256(“R0 Key Name” || SSID || MDID || R0KH-ID || 0x00 || SPA || ANonce)) PMK-R1 = KDF-256(PMK-R0, "R1 Key Derivation", PMKR0Name || R1KH-ID || 0x00 || SPA) –PMK-R0 is the top level key in the FBT Key Hierarchy. –"R1 Key Derivation" is the literal string consisting of the sequence of letters 'R', '1', ' ', 'K', 'e','y', ' ', 'D', 'e', 'r', 'i', 'v', 'a', 't', 'i', 'o', and 'n' (no null terminator). –PMK-R0-Name is defined in section 8.5A.4.8.5A.4 –R1KH-ID is the 16-octet identifier of the holder of PMK-R1. –SPA is the STA's MAC address PMKR1Name = Truncate-128(SHA-256(“R1 Key Name” || PMKR0Name || R1KH-ID ||0x00 || SPA)) The parameters are all not variable. At the same time as the parameters do not change, the result will not change, too. This means if the higher hierarchy key is not change, the key deriving from it will not change every time. Based on this we propose a new method to rederive the key hierarchy. Using this method, the key hierarchy could be refreshed periodically without re-authentication.

doc.: r Submission March 2006 AllSlide 7 solution As describe above, we introduce variable parameters into the PMK-R0 deriving. When PMK-R0 lifetime expires, reauthentication don’t need, the PMK-R0 key holder use “MSK”, variable parameter, and other parameter to derive a new PMK-R0. The PMK-R0 key holder could send the variable parameters to the STA either via the DS or via the air.

doc.: r Submission March 2006 AllSlide 8 New Key deriving We introduce a variable parameter B into the PMK-R0 deriving: PMK-R0 = KDF-256(XXXKey, "R0 Key Derivation", SSID || MDID || R0KH-ID || B || 0x00 || SPA) As a result, when PMK or PTK lifetime expires or the key being compromised, reauthentication needn’t, only derive a new PMK-R0 using the primary MSK or PSK needed.

doc.: r Submission March 2006 AllSlide 9 How to transfer “B” to STA Variable parameter “B” is random produce at R0KH, in order to deriving PMK-R0 at the STA ， The R0KH need to transfer the “B” to STA. Parameter “B” can sent to STA in the authentication response message by AP.

doc.: r Submission March 2006 AllSlide 10 First contact During the first contact, after successful complete the 802.1X authentication, authenticator generates Anonce and parameter “B”, than it calculate PMK-R0 and PMK-R1, and the AP sent parameter “B” to the STA in the first message of 4-way handshake.

doc.: r Submission March 2006 AllSlide 11 Rederiving hierarchy key When the keys being compromised or the key lifetime expired, it needn’t reauthenticator, STA and authenticator can still use the Primary XX-KEY to derive new PMK-R0 and PMK-R1 with the new “B”, the ANONCE could be changed or not.

doc.: r Submission March 2006 AllSlide 12 Transfer “B” during FT During the FT, parameter “B” could be sent to STA along with anonce by authenticator.