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

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

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

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

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

6. STAKey Security Flaws Flaw 1: STAKey Generation Undefined
Neither IEEE i™─2004 nor IEEE e/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

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

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