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

Goals and Motivation Simplification of protocol and interoperability Month Year doc.: IEEE 802.11-yy/xxxxr0 July 2005 Goals and Motivation Simplification of protocol and interoperability Per 11-05-0726-01-000r-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-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

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

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

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

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

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

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