1. doc.: IEEE 802.11-06/0623r0 Submission May 2006 Sood, Walker, ZhaoSlide 1 A Method to Protect TGr Reservation Scheme 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, 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2006-05-15 Authors:

2. doc.: IEEE 802.11-06/0623r0 Submission May 2006 Sood, Walker, ZhaoSlide 2 Abstract This submission proposes a mechanism to limit the number of simultaneous 802.11r reservations an authorized STA can make, in order to address multiple LB 82 comments.

3. doc.: IEEE 802.11-06/0623r0 Submission May 2006 Sood, Walker, ZhaoSlide 3 Agenda Reservation Vulnerabilities Security Requirements Proposed Protocol Design Proposal Assumptions Design Properties Summary Straw Poll

4. doc.: IEEE 802.11-06/0623r0 Submission May 2006 Sood, Walker, ZhaoSlide 4 Reservation Vulnerabilities: Flooding attacks (Ref: 11-06-0624) The P802.11r D2.0 design has no mechanism to limit the number of reservations made by any client Attack: –Step 1: for each AP in the mobility domain use over-the-DS to send that AP a reservation request An AP could implement a metering scheme to prevent over-the-DS abuse of reservation Alternate attack –Step 1: spread the colluding clients across the mobility domain –Step 2: for each mobility domain AP within range, use over-the-air to send that AP a reservation request

5. doc.: IEEE 802.11-06/0623r0 Submission May 2006 Sood, Walker, ZhaoSlide 5 Reservation Vulnerabilities: Flooding attacks (Ref: 11-06-0624) With either approach a small number of clients can allocate all of the bandwidth in the mobility domain Recommendation: impose an enforceable metering scheme that is applied to both over-the-air and over-the DS, or else remove reservation

6. doc.: IEEE 802.11-06/0623r0 Submission May 2006 Sood, Walker, ZhaoSlide 6 Security Requirements Limit the number of APs at which reservations can be made by a STA regardless of the mechanism used –Should work for both Over-the-Air and Over-the-DS Reservation Requests cannot be forged by any party, including –Any STA –the Current AP –Any other AP Reservation requests cannot be reused by a STA on multiple APs, ie. Each reservation request is distinct A third party cannot hijack the reservation request for use with other APs, e.g., Current AP cannot act as STA’s proxy

7. doc.: IEEE 802.11-06/0623r0 Submission May 2006 Sood, Walker, ZhaoSlide 7 Proposed Protocol Design: Concept The client create a 1-way hash chain as a sequence of reservation tokens H 0, H 1, H 2, …, H n with H n as the chain root and H 0 the chain commit value The client registers the chain commit value H 0 with an Authorization Server (AzS) The client “spends” one reservation token with each reservation The AzS verifies that H 0 = h i (H i ) and that i > j, where j is the largest index of any token received thus far, to authorize the reservation

8. doc.: IEEE 802.11-06/0623r0 Submission May 2006 Sood, Walker, ZhaoSlide 8 Proposed Protocol Design: Phase 1 Message Flow (“Open an account”) STACurrent APAzS Secure Association STA generates random R Request(SA, R) := SA || R AzS generates random C Response(SA, R, C) := SA || R || C || MIC K (SA || R || C) STA generates hash chain H n–1 = h(H n || C), …, H 0 = h(H 1 || C) IsAuthorized = FALSE Confirm(SA, C, H 0 ) := SA || C || H 0 || MIC K (SA || C || H 0 ) Success IsAuthorized = TRUE

9. doc.: IEEE 802.11-06/0623r0 Submission May 2006 Sood, Walker, ZhaoSlide 9 Proposed Protocol Design: Phase 2 Message Flow (“Spend from account”) STACurrent APTarget AP i AzS Res Request(SA || H i ) SA || H i OK or Deny Res Request(SA || H i+1 ) SA || H i+1 OK or Deny Target AP i+1

10. doc.: IEEE 802.11-06/0623r0 Submission May 2006 Sood, Walker, ZhaoSlide 10 Proposed Protocol Design: Key and Hash Chain Construction Let KDK = bits 256..511 of AAA Key Let K = kdf(KDK, “Reservation Key Derivation,” SA || Mobility- Domain-ID || R || C) where kdf is the 802.11r key derivation function, R is the STA’s random value, and C is the AzS’s challenge –K is an end-to-end key between STA and AzS Choose H n randomly and let C be the AzS challenge value. Then define H n–1 = SHA-256(H n || C) H n–2 = SHA-256(H n–1 || C) … H 0 = SHA-256(H 1 || C)

11. doc.: IEEE 802.11-06/0623r0 Submission May 2006 Sood, Walker, ZhaoSlide 11 Other Protocol Details STA gets Reservation-Limit n through a source authenticated, forgery protected message –Message #3 in TGr Initial Association 4-way handshake Current AP prohibits additional Phase-I executions after one is completed successfully STA executes reservation transaction with each Target AP sequentially Spending phase messages can be embedded within TGr messages

12. doc.: IEEE 802.11-06/0623r0 Submission May 2006 Sood, Walker, ZhaoSlide 12 Protocol Design Assumptions Each AP has a forgery protected (source authenticated) channel with the Authorization Server (AzS) The protocol end-points for STA  AS and AP  AS are one and the same AS Reservations are short-lived

13. doc.: IEEE 802.11-06/0623r0 Submission May 2006 Sood, Walker, ZhaoSlide 13 Properties STA can get at most n tokens as long as it is associated with the Current AP. –If STA spends n tokens and does not move from that AP, then it cannot get any more tokens while associated with that AP –Means that either (a) STA spends all tokens and must move using one of those tokens, or (b) Spends tokens and later moves with no reservation –Corollary: Mandatory Reservation can result in STA lockout STA can make at most 2n reservations before transitioning –STA acquires n tokens while associated with Current AP –STA transitions to AP1, without using any tokens –STA spends n tokens at AP1 by making n reservations –STA executes Phase-I at AP1 to get n more tokens –STA spends n tokens at AP1 by making n more reservations

14. doc.: IEEE 802.11-06/0623r0 Submission May 2006 Sood, Walker, ZhaoSlide 14 Properties (Contd.) STA must spend the tokens in the right order –Since the protocol relies on a hash chain, an attacker can calculate earlier token hashes from later tokens. –For example: If attacker gets H 3 before transaction of H 2 is completed, then H 2 can be forged and losses cryptographic properties of this design. –Corollary: This scheme does not permit parallelism inherent in over-the-DS reservations Reservation cancellation, revocation and expiration procedures have not been addressed

15. doc.: IEEE 802.11-06/0623r0 Submission May 2006 Sood, Walker, ZhaoSlide 15 Properties (Contd.) This protocol allows a STA to consume all the resources at any AP –The protocol limits the reservation scheme to a maximum number of APs, NOT on the resources that can be reserved in each request. This protocol does not deal with delayed or lost messages –They are considered “lost” and STA needs to send a new request every time. If not, then risks being rejected by the AS.

16. doc.: IEEE 802.11-06/0623r0 Submission May 2006 Sood, Walker, ZhaoSlide 16 Summary Currently, no mechanism exists to protect the reservation scheme. –A viable security design will help address significant number of TGr LB comments Based on the security requirements, we have proposed a mechanism that meets these goals We’d welcome collaborators and suggestions to enhance this scheme, alternate scheme(s), etc. Straw poll…

17. doc.: IEEE 802.11-06/0623r0 Submission May 2006 Sood, Walker, ZhaoSlide 17 Straw Poll Would you like normative text for this mechanism submitted for inclusion into the TGr draft? Yes: No:

18. doc.: IEEE 802.11-06/0623r0 Submission May 2006 Sood, Walker, ZhaoSlide 18 Discussion?