1. 2-Level Key Hierarchy Date: 19 July 2005 Authors: July 2005 Month Year
doc.: IEEE yy/xxxxr0
July 2005
2-Level Key Hierarchy
Date: 19 July 2005
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
K. Sood, J. Walker, N Cam-Winget
John Doe, Some Company

2. Goals and Motivation Simplification of protocol and interoperability
Month Year
doc.: IEEE yy/xxxxr0
July 2005
Goals and Motivation
Simplification of protocol and interoperability
Per r-auth-framework-preso.ppt complexities brought on by 3-level key hierarchy need to be addressed.
K. Sood, J. Walker, N Cam-Winget
John Doe, Some Company

3. 3-Level Key Hierarchy Potential security vulnerabilities
July 2005
3-Level Key Hierarchy
Potential security vulnerabilities
Missing key management protocol to bind PMK-R1 to its context
Protocol overhead
Extra layer of keys that need protection and management
50% greater cost in memory and key derivation MIPS
Advertisement bloat needed to make key binding secure
WLAN deployment and management issues
Naming bloat
More systems fail not because of protocols, but because of poor deployment and faulty management
“Why Cryptosystems Fail” – By Ross Anderson
Harder security analysis for 3 levels, and less assurance of the security properties
Protocol Overhead
More end-to-end keys between multiple entities involved
Entities must treat each other as having a separate key boundary
K. Sood, J. Walker, N Cam-Winget

4. 2-Level Key Hierarchy Potential security vulnerabilities
July 2005
2-Level Key Hierarchy
Potential security vulnerabilities
Implementation temptation to not treat lightweight APs under a centralized NAS as separate key spaces
Protocol Overhead
More end-to-end keys between first contact NAS and transitioning authenticator NAS
NAS must treat each one as having a separate key boundary
WLAN Deployment and Management
Requires more end-to-end security between NASes
K. Sood, J. Walker, N Cam-Winget

5. 2-Level Deployment Architectures
July 2005
2-Level Deployment Architectures
NAS1 is required to “know” about every Authenticator on the LAN, to derive and directly deliver protected PMK-R1 keys
AAA Services
R0 Binds to NAS1
NAS1
AP1
NAS2
AP2
R1 Binds to NAS2
PMK-R0
PMK-R1-2
PMK-R1-1
Derive PTKs
R1 Binds to NAS1 1 2
STA
STA
Classic “Fat” AP Model
Indicates mutually authenticated and protected channel between the end-points
Indicates protected key scope and boundary
K. Sood, J. Walker, N Cam-Winget

6. 2-Level Deployment Architectures (Contd.)
July 2005
2-Level Deployment Architectures (Contd.)
NAS1 is required to “know” Authenticators on LAN like NAS2 (and other NAS-es), to derive and directly deliver protected PMK-R1 keys
AAA Services
R0 Binds to NAS1
Authenticator: R1-2 Binds to NAS2-Authenticator (NAS-Id)
NAS1
Controller1
NAS2
Controller2
PMK-R0
Authenticator: R1-1 Binds to NAS1-Authenticator (NAS-Id)
PMK-R1-1
PMK-R1-2
Derive PTKs 2 4 1 3
AP1
AP2
AP3
AP4
STA
STA
STA
STA
Indicates mutually authenticated and protected channel between the end-points
Controller AP Model with multiple Authenticator
Indicates protected key scope and boundary
K. Sood, J. Walker, N Cam-Winget

7. July 2005
NAS-Id is Key Holder Id
Key holders should be well-defined using known and specified identifiers.
Security requires that R0KH and R1KH have authenticated
To address manageability and minimize configuration costs, identities used in above authentication must be advertised.
R0KH is the authenticator from AAA view, and hence, binds to NAS-Id
R1KH is the Authenticator from AP view, and hence, binds to NAS-Id
K. Sood, J. Walker, N Cam-Winget

8. Proposed 2-Level Key Derivation
July 2005
Proposed 2-Level Key Derivation
PMK-R0 = KDF-256 (MSK, “R0 Key Derivation”, SSID || R0KH-ID || 0x00 || SPA)
PMK-R0-Name = SHA-256(“R0 Key Name” || SSID || R0K0-ID || 0x00 || SPA)
PMK-R1 = KDF-256( PMK-R0, “R1 Key Derivation”, PMK-R0-Name || R1KH-ID || 0x00 || SPA)
PMK-R1-Name = SHA-256(“R1 Key Name” || PMK-R0-Name || R1KH-ID || 0x00 || SPA)
PMK-R2 = KDF-256( PMK-R1, “R2 Key Derivation”, PMK-R1-Name || BSSID || SPA)
PMK-R2-Name = SHA-256(“R2 Key Name” || PMK-R1-Name || BSSID || SPA)
PTK = KDF-PTKLen(PMK-R2, “PTK Key derivation”, SNonce || ANonce || R0-NASID || R1-NASID || BSSID || SPA)
PTKName = SHA-256(PMK-R2-Name || “PTK Name” || SNonce || ANonce || BSSID || SPA)
K. Sood, J. Walker, N Cam-Winget

9. July 2005
Motion
Instruct the TGr editor to accept the changes highlighted in r0
K. Sood, J. Walker, N Cam-Winget