TAP & JIT Key Hierarchy Notes Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2005 TAP & JIT Key Hierarchy Notes Date: 2005-03-15 Authors: Notice: This document has been prepared to assist IEEE 802.11. 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 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, 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 <stuart.kerry@philips.com> 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Nancy Cam-Winget and Kapil Sood John Doe, Some Company

Merging TAP & JIT Key Hierarchies March 2005 Merging TAP & JIT Key Hierarchies Focus of discussions: Above PTK key derivations PTK key derivation PRF considerations 3 party binding issues Key Naming Key Holder Entities Naming NIST Considerations Questions for Russ Nancy Cam-Winget and Kapil Sood

Proposed Merged Key Hierarchy March 2005 Proposed Merged Key Hierarchy SID = Session ID from EAP, or init by STA (optional) SA = STA MAC addr AA = BSSID NASID = 802.1X authenticator ID EAP-ID = EAP Identity used to Authenticate supplicant in EAP exchange (optional) PMK-R0 256 bits (e.g. called PMK in 802.11i, or result from successful EAP) PRF-384( PMK-R0, EAP-ID**|| SID** || SA || LPSID || “LSKey derivation”, 384) PCK-R1 128 bits PMK-R1 256 bits PRF-384( PMK-R1, EAP-ID** || SID **|| SA || NASID || “PMKey derivation”, 384) PCK-R2 128 bits PMK-R2 256 bits PRF-XXX(PMK-R2, SNonce || ANonce || LPSID || NASID || SA || AA || “PTKey derivation”, 256+TKlen) KCK 128 bits KEK Temporal Key (TK) L(PTK,256,TKlen) PTK (x bits) Nancy Cam-Winget and Kapil Sood

Focus Areas Above PTK Key Derivation March 2005 Focus Areas Above PTK Key Derivation Need to have 2 distinct key hierarchies: NIST vs. non-NIST to address differing key construction Along the key hierarchy, map the keys to the STA's MAC address A new key hierarchy naming PMK-R0 at top level; PMK-R1 intermediate level; PMK-R2 at lower level (maps to RSK/PMK, LSK/D-PMK, PMK/DA-PMK respectively) At association the STA has to assert the use of the key hierarchy (e.g. 11r vs. 11i) Nancy Cam-Winget and Kapil Sood

Focus Areas PTK Key Derivation PRF Considerations March 2005 Focus Areas PTK Key Derivation Adopt the counter mode construction of the PTK, pending review from Russ PRF Considerations PRF to use: 802.11i vs. FIPS 186-2 or other? Adopt KDF from JIT and present to NIST to see if they will approve on a "permanent" basis and/or for security review 802.11i KDF construction is vulnerable to sliding parameter attacks, but no known methods to launch this attack against 11i construction Nancy Cam-Winget and Kapil Sood

March 2005 Focus Areas Key Naming Agreement that PMK-R0 needs a name, but controversy around naming intermediate level keys Talk to Russ about same key names along key hierarchy, and if so, there needs to be explicit request/action to ensure that provisioning of the keys are done at the appropriate level. Talk to Russ about key naming mechanisms Nancy Cam-Winget and Kapil Sood

Focus Areas 3-party Key Binding March 2005 Focus Areas 3-party Key Binding Need to come up with a way to make sure that there's a secure 3 party protocol to ensure that the 3rd party is authorized to receive the key. Nancy, Dan and Kapil captured the problem for 3-party binding Problem statement To retain the trust model that is currently defined in 11i,  it's necessary to have a 3-party protocol to distribute keys.  It is necessary for the Supplicant to authorize the disclosure of the key and not just allow the keys to be available in any arbitrary location.  The keys should be explicitly bound to the authenticated key endpoints. Nancy Cam-Winget and Kapil Sood

Focus Areas Key Holder Entity Naming Questions for NIST March 2005 Focus Areas Key Holder Entity Naming LPSID/EKCID, NASID/ KCID PMK-R0 name can be an abstract blob.  Advertised on Beacons/Probes.....fixed at 16octets Do we need to name all entities? With this key hierarchy, can STA use only one PMK-R0 name?  Questions for NIST What identities need to be bound into the key hierarchy? Can the new KDF construction be approved by NIST (more permanently than TGi's)? Need to ensure the key naming is approved by NIST Nancy Cam-Winget and Kapil Sood

Focus Areas Meeting with Russ Housley: Wed, 3/16/05, 2pm in Kennesaw March 2005 Focus Areas Meeting with Russ Housley: Wed, 3/16/05, 2pm in Kennesaw  Questions for Russ Why did 11i have to bind SA and AA into the PTK (was it because PSK)?  PTK counter mode construction evaluation Need to bind the LPSID to the PMK derivation (the middle layer). Any issues with KDF? Can we name the key based on the function of the key itself?  Why can't we use the same construction to 802.11i. Why 802.11i bound the SA and AA into the PTK (was it because PSK)? Can and should the name of the key be the same all along the key hierarchy? Is IKEv2 NIST approved, if so what modes? Discuss the 3 party binding Nancy Cam-Winget and Kapil Sood