Extended Usage of STKSA

1. Extended Usage of STKSA Authors: Date: 2008-3-14 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. Hu Junling

2. Abstract Extended use cases of STKSA and the imaginable solutions for these use cases are described in this slides deck. Hu Junling

3. Use Case 1(see contribution 11-09-2916 also) • Two QSTAs are assoicated with an AP which does not support Security. • The two STAs want to exchange security datum,but the AP path is not secure. • DL can be used just for secure transmitting. • The STKSA can be setup manually or through other certain special approach. AP Not secure Secure Initiator STA Peer STA SMK is entered into STAs manually before DLS starting. Hu Junling

4. Use Case 1(see contribution 11-09-2916 also) • Even peer STA moves away and AP path is used, STKSA can be kept in AP path. • The STAs still used STK to protect the data, but the protected data is encapsulated in tunnel. AP Path secure tunnel AP Secure Initiator STA Peer STA Hu Junling

5. Two QSTAs are assoicated with an AP which support Security. The AP need to decrypts the data frame and encrypts it again when the AP transmits the data frames from one STA to the other. STA1 initiates DLS with STA2 because of bad QoS and the DLS is succeeded. Use case 2 AP encrypts the data by PTK2. AP decrypts the data by PTK1. AP AP transmits the data frames protected by PTK2 to STA2. STA1 sends data frames protected by PTK1 to AP. Direct Link STA1 STA2 Hu Junling

6. Now, the STA2 moves, the direct link can not be used, so the data path is switched to AP path. STK is still used for protect the data between STAs and AP. The AP does not decrypt the data and encrypt it again before transmit it to peer STA since the data frame is protected by STK, so the burden of the AP is decreased. Use case 2 AP path AP Data frame protected by STK Direct Link STA1 STA2 Hu Junling

7. Two QSTAs are assoicated with an AP which support Security. STKSA can be used only for decreasing the burden of AP when the DL cann’t be setup essentially due to STA1 is too far away from STA2 or other reasons. The STKSA is created through AP path entirely. Date frames between STA and AP are protected by STK and AP do nothing for the data when the AP transmit it. Use case 3 Create STKSA AP Data frame, protected by STK STA2 Direct Link can not be setup STA1 Hu Junling

8. Solution 1(for use case 1) • For use case 1, the Remote Frame Type field in TDLS frame bodyshall be set to 3 for tunneled secure frames (value 2 of RFT field has been defined for TDLS frames. See figure z1). Figure z1—TDLS frame body • A new table z2 is added to define the Packet Type values for tunneled secure frames: New Table Z2 Hu Junling

9. Solution 2(for use case 2 and 3) • For use case 2, a reserved bit in KeyID octet can be used to indicate that the frame is protected by station to station keys. 0: Normal 1: Protected by SMK/STK • WPA defined that KeyID value 0 is used for PTK and values 1 to 3 are used for GTK, but WPA also suggest that value 3 is reserved. So we can define the value 3 of KeyID for station to station keys. 00: PTK 01, 10: GTK 11: SMK/STK Hu Junling

10. Straw poll • Do you think it is a practical method using STK to protect data frames in both direct path and AP path in the use case 1? • Yes/No/Unknown: • Do you think it is a effective method using STK to protect data frames in AP path to decrease the burden of the AP in use case 2 and 3? • Use case 2: Yes/No/Unknown: • Use case 3: Yes/No/Unknown: Hu Junling