1. TGr Security Architecture
Month Year
doc.: IEEE yy/xxxxr0
September 2006
TGr Security Architecture
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
Sood et.al.
John Doe, Some Company

2. Month Year
doc.: IEEE yy/xxxxr0
September 2006
TGr Security Design
Instrument this design in context of state machines and in relation to 802.1X
Sood et.al.
John Doe, Some Company

3. TGr Security Architecture
Month Year
doc.: IEEE yy/xxxxr0
September 2006
TGr Security Architecture
Sood et.al.
John Doe, Some Company

4. TGr PTK Key Derivation September 2006 PMK - R 1 KEK KCK 11 X TK PTK
Month Year
doc.: IEEE yy/xxxxr0
September 2006
TGr PTK Key Derivation
PMK - R 1
KEK
KCK 11 X TK ,
TK remain within SME
and plumbed into MAC
X is sent into
802 .
PTK
Sood et.al.
John Doe, Some Company

5. TGr Key Hierarchy (Contd.)
Month Year
doc.: IEEE yy/xxxxr0
September 2006
TGr Key Hierarchy (Contd.)
R0KH receives MSK from AS
R0KH derives PMK-R0 from MSK
R0KH generates multiple PMK-R1 keys and sends to R1KHs
PTK Keys
4 keys: KEK, KCK-11, TK, KCK-1X
KEK and KCK-11 are consumed by SME: SME uses KEK to wrap KDEs and KCK11 to MIC 11r frames
KCK-1X is consumed by .1X used to MIC .1X frames
KCK-1X authenticates GTK updates and TKIP countermeasures
Sood et.al.
John Doe, Some Company

6. TGr Initial Association
Month Year
doc.: IEEE yy/xxxxr0
September 2006
TGr Initial Association
Sood et.al.
John Doe, Some Company

7. TGr Initial Association ANonce
Month Year
doc.: IEEE yy/xxxxr0
September 2006
TGr Initial Association ANonce
R0KH and R1KH are within the same crypto boundary
Because the R0KH and R1KH both need assurance that the ANonce is fresh and unpredictable
ANonce was mixed into the key hierarchy to give distinct PMK-R1 Names. Four alternatives are discussed:
Extend additional keying material in PMK-R0 for use in PMK-R0 Name derivation
Extend additional keying material in PMK-R1 for use in PMK-R1 Name derivation
Use of EAP-Session-Id in PMK-R0 Name derivation
Have R1KH and R0KH generate independent ANonces, and deliver both to the STA
Sood et.al.
John Doe, Some Company

8. Comments on Initial Association ANonce
September 2006
Comments on Initial Association ANonce
In Initial Association, Anonce is generated by “the” R1KH and sends to R0KH. We call it IA-Anonce.
It is used twice.
As input to R0 Key Name by R0KH; and
As input to PTK by “the” R1KH.
Serve for different purposes
As an input to R0 key Name, which is the input to all R1 keys, it will distinguish these R1 keys from the R1 keys generated previous and afterwards.
As an input to PTK, it serves as an implicit authentication challenge to STA. This is the same as used in FR Re-association.
Initial Association and FT Re-association will have different Anonce procedure for PTK (see picture)
For initial association, use the same IA Anonce to derive PTK;
For FT re-association, R1KH generates a new Anonce for PTK.
No matter R0KH or R1KH generates Anonce, it must be shared.
It shall be modified so that the Anonce will be used only to derive PTK, no matter in Initial Association or FT Re-association.
R0 key
R0 key Name
IA-Anonce
The R1 key
R1 key a
R1 key b
R1 key c
PTK
IA-Anonce
PTK a
PTK b
PTK c
This is generated in Initial Association
Anonce a
Anonce b
Anonce c
This is generated in FT Re-Association
Sood et.al.

9. Discussions on 4 Alternatives
September 2006
Discussions on 4 Alternatives
In Initial Association, have R0KH generate an “Rnonce” and use it in R0Name. Then have “the” R1KH generate an Anonce and use it for PTK as in FT Re-Association.
This is ideal from security point of view.
It will not require “the” R1KH to be involved until it receives a R1 key.
However, we will need a message to deliver Rnonce to STA.
Extend the PMK-R0 keying material to allow using a segment as input to the R0 key name. “The” R1KH generates Anonce for PTK.
Assume the key derivation function is a pseudorandom function. The two non output overlap segments should be independent. That is, if one segment is compromised, it should net leak any information about another segment.
No need for R0KH to generate and to deliver nonce. Therefore, no impacts on protocols.
Extend the PMK-R1 keying material to allow using a segment as input to the R1 key name. “The” R1KH generates Anonce for PTK.
Eliminate the need for R0 name. No need for R0KH to generate and to deliver nonce. Therefore, no impacts on protocols.
Same security implication/assumption as the above.
Since it makes every PMK-R1 derivation longer, it is not as efficient as the above.
Use EAP-Session-Id in PMK-R0 Name derivation, “The” R1KH generates Anonce for PTK.
EAP-Session-Id must be available to R0KH.
Sood et.al.

10. TGr FT Reassociation – Base Mechanism
Month Year
doc.: IEEE yy/xxxxr0
September 2006
TGr FT Reassociation – Base Mechanism
Sood et.al.
John Doe, Some Company

11. GTK Updates Either the SME or the 802.1X can trigger the GTK update
Month Year
doc.: IEEE yy/xxxxr0
September 2006
GTK Updates
Either the SME or the 802.1X can trigger the GTK update
Message format and flow remains the same as 11i
802.1X requests SME to wrap KDEs
On AP, 802.1X originates the GTK update messages
Supplicant asks SME to unwrap and plumb GTK into MAC
Sood et.al.
John Doe, Some Company

12. TGr Design Impacts No EAPOL-Key Frames (EAPKIE) in any 11r messages
Month Year
doc.: IEEE yy/xxxxr0
September 2006
TGr Design Impacts
No EAPOL-Key Frames (EAPKIE) in any 11r messages
Existing 11r message formats will need to be modified
A separate MIC IE within the TGr messages
Over-the-Air and Over-the-DS end-to-end message contents can be harmonized, since both will now be processed by the SME
Security sections need to be modified to include this architecture, update key hierarchy
Either duplicate the 11i state machine to adjust for 11r Initial Association, OR, add a flag in 11i state machine to make it use 11r key as opposed to 11i PMK
Sood et.al.
John Doe, Some Company

13. Month Year
doc.: IEEE yy/xxxxr0
September 2006
The following slides capture the updates to TGr security design discussed at the TGr adhoc Meeting in Portland – June 20-22, 2006
Sood et.al.
John Doe, Some Company

14. Make PMK-R1-Names Unique across Key Hierarchies
Month Year
doc.: IEEE yy/xxxxr0
September 2006
Make PMK-R1-Names Unique across Key Hierarchies
Update the PMK-R0 key derivation to derive additional keying material. This new key material will be used as an input into the PMK-R0-Name derivation, which will make PMK-R1-Names unique for every instantiation of the key hierarchy.
PMK-R0-Key-Blob = KDF-512(…keep same params as in PMK-R0 key derivation…)
PMK-R0 = L (PMK-R0-Key-Blob, 0, 256)
First 256 bits (out of 512) of the KDF output is used as PMK-R0 key
PMK-R0-Name-Salt = L (PMK-R0-Key-Blob, 256, 256)
Next 256 bits of KDF used as Random nonce into PMK-R0-Name
PMK-R0-Name = Truncate-128(SHA-256(…same params…, ANonce, PMK-R0-Name-Salt)
Sood et.al.
John Doe, Some Company

15. TGr Initial Association (No ANonce in PMK-R0)
Month Year
doc.: IEEE yy/xxxxr0
September 2006
TGr Initial Association (No ANonce in PMK-R0)
Sood et.al.
John Doe, Some Company

16. Identity of the PMK-R1 KH
Month Year
doc.: IEEE yy/xxxxr0
September 2006
Identity of the PMK-R1 KH
The group decided to name the PMK-R1 Key Holder (KH) – set the identity of this entity – as the MAC address of the physical entity that is the authorized holder of the PMK-R1 key.
This identity has to be advertised by the AP at all times – in beacons, probes, and all TGr messages
R1KH-ID exists in TGr messages
So, add to beacons/probes? Open Question.
Update Section on PMK-R1 keys to state that the value of the R1KH-ID is a MAC address
Remove the MIB variable dot11FTR1KeyHolderID
Sood et.al.
John Doe, Some Company

17. TGr Security Architecture
Month Year
doc.: IEEE yy/xxxxr0
September 2006
TGr Security Architecture
The group felt the proposed security architecture may be too complex
Proposed to extend the i architecture diagram to include the new entities (R0KH and R1KH) as part of the RSNA Key Management.
State machines need to be updated/added to address the interaction among various components of the security architecture.
Decided to add a new KCK-11 key to differentiate the 11r Initial Association Handshake (KCK) key from the 11r FT Mechanism (KCK-11) key – as performed by different entities
Sood et.al.
John Doe, Some Company

18. TGr Security Architecture Diagram (from White Board)
Month Year
doc.: IEEE yy/xxxxr0
September 2006
TGr Security Architecture Diagram (from White Board)
Sood et.al.
John Doe, Some Company