1. TAP & JIT Key Hierarchy Notes
Month Year
doc.: IEEE yy/xxxxr0
March 2005
TAP & JIT Key Hierarchy Notes
Date:
Authors:
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 < 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 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
Nancy Cam-Winget and Kapil Sood
John Doe, Some Company

2. 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

3. 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 i, 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

4. 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

5. 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: i vs. FIPS 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

6. 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

7. 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

8. 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

9. 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 i.
Why i 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