STAKey Design Flaws Date: 2005-11-04 Jesse, Shlomo, Suman 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>. Jesse, Shlomo, Suman

Outline: Why STAKey needed? CE Usage Model STAKey Security Flaws STAKey Definition Flaw Proposal to 802.11 TGw Jesse, Shlomo, Suman

Why STAKey needed ? Protects direct STA-to-STA communication in BSS mode Used by any application for secure STA-to-STA link in BSS Used for providing secure Direct Link set-up (DLS) Defined in recently ratified draft Standard (IEEE P802.11e/D13.0) Needed to support delay sensitive applications such as voice and video streaming from PC to multiple digital entertainment devices Jesse, Shlomo, Suman

Direct Link Set-up (DLS) QSTAs may transmit frames directly to another QSTA using DLS. DLS does not apply in QIBSS (frames are always sent directly). QSTA-A sends DLS request (1a) to QAP (i.e., QSTA-A capabilities, QSTA-A/B MAC addresses, rate set). QAP forward the DLS request to QSTA-B (1b) if it is associated in the BSS QSTA-B sends DLS response to QAP (2a) if it accepts the direct stream request of QSTA-A. QAP forward the DLS response to QSTA-A (2b) – DLS becomes active Jesse, Shlomo, Suman

CE Usage Model Initiator STA: PC/Handheld/Cell Phone Peer STA: Home TV Initiator STA & Peer STA perform RSNA exchange with AP Both STAs get their own PTK Initiator STA creates DLS link with Peer STA with help of AP Using DLS message exchange Initiator STA starts STAKey key exchange with Peer STA Needed to secure the communication between STAs Needs two set of STAKeySA to support bidirectional traffic DLS Jesse, Shlomo, Suman

STAKey Security Flaws Flaw 1: STAKey Generation Undefined Neither IEEE 802.11i™─2004 nor IEEE 802.11e/D13 Standards describe how the STAKey is generated Open to all attacks against Weak Key Flaw 2: No Binding with STAKey Sessions STAKey key exchange doesn’t call out the generation of different keys for different sessions Key reuse which can cause man in middle attack Flaw 3: No 4-Way Handshake STAKey exchange between STA’s doesn’t use 4-way handshake to confirm the existence of key derivation with each other No synchronization of key can cause man in middle attack Jesse, Shlomo, Suman

STAKey Definition Flaw STAKey message exchange is initiated by STA-A (blue) and STA-B (red) STA-A receives two messages (A4 and B2) from AP to install two different STAKey for two different STAKey message exchanges Since there is no STAKey messages ordering requirement, A4 and B2 can reach STA-A in any order STA-A can’t differentiate between these two messages (i.e. which message contains Rx STAKey and which contains Tx STAKey). STA-B gets into same problem with STAKey messages A2 and B4. STAKey key exchange incomplete Not possible to implement STAKey is unidirectional ─ two set of independent key exchange are required to provide security for bidirectional traffic A4 STA-A EAPOL-Key(1,1,1,0,G/0,0,0, MIC, 0,B MAC KDE, STAKey1) B2 STA-B EAPOL-Key(1,1,1,0,G/0,0,0, MIC, 0, B MAC KDE, STAKey2) Jesse, Shlomo, Suman

Proposal to 802.11 TGw Is group willing to do this work ? If so, is this work within the PAR of TGw or PAR change is needed ? Jesse, Shlomo, Suman