May 2006

Sood, Walker, ZhaoSlide 1

doc.: IEEE 802.11-06/0623r0

Submission

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

Date: 2006-05-15

Name Company Address Phone email Kapil Sood Intel Corporation

2111 NE 25th Ave JF3-206 Hillsboro OR 97124

+1-503-264-3759 kapil.sood@intel.com

Jesse Walker Intel Corporation 2111 NE 25th Ave JF3-206, Hillsboro OR 97124

503-264-3759 jesse.walker@intel.com

Meiyuan Zhao Intel Corporation 2111 NE 25th Ave JF3-206, Hillsboro OR 97124

503-712-4990 Meiyuan.Zhao@intel.com

Authors:

May 2006

Sood, Walker, ZhaoSlide 2

doc.: IEEE 802.11-06/0623r0

Submission

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.

May 2006

Sood, Walker, ZhaoSlide 3

doc.: IEEE 802.11-06/0623r0

Submission

Agenda

• Reservation Vulnerabilities

• Security Requirements

• Proposed Protocol Design

• Proposal Assumptions

• Design Properties

• Summary

• Straw Poll

May 2006

Sood, Walker, ZhaoSlide 4

doc.: IEEE 802.11-06/0623r0

Submission

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

May 2006

Sood, Walker, ZhaoSlide 5

doc.: IEEE 802.11-06/0623r0

Submission

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

May 2006

Sood, Walker, ZhaoSlide 6

doc.: IEEE 802.11-06/0623r0

Submission

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

May 2006

Sood, Walker, ZhaoSlide 7

doc.: IEEE 802.11-06/0623r0

Submission

Proposed Protocol Design: Concept

• The client create a 1-way hash chain as a sequence of reservation tokens H0, H1, H2, …, Hn with Hn as the chain root and H0 the chain commit value

• The client registers the chain commit value H0 with an Authorization Server (AzS)

• The client “spends” one reservation token with each reservation

• The AzS verifies that H0 = hi(Hi) and that i > j, where j is the largest index of any token received thus far, to authorize the reservation

May 2006

Sood, Walker, ZhaoSlide 8

doc.: IEEE 802.11-06/0623r0

Submission

Proposed Protocol Design: Phase 1 Message Flow (“Open an account”)STA Current AP AzS

Secure AssociationSTA

generates random R Request(SA, R) := SA || R

AzS generates random CResponse(SA, R, C) := SA || R || C || MICK(SA || R || C)

STA generates hash chain Hn–1 =

h(Hn || C),

…, H0 = h(H1 || C)

IsAuthorized = FALSE

Confirm(SA, C, H0) := SA || C || H0 || MICK(SA || C || H0)

SuccessIsAuthorized = TRUE

May 2006

Sood, Walker, ZhaoSlide 9

doc.: IEEE 802.11-06/0623r0

Submission

Proposed Protocol Design: Phase 2 Message Flow (“Spend from account”)

STA Current AP Target APi AzS

Res Request(SA || Hi)SA || Hi

OK or DenyOK or Deny

Res Request(SA || Hi+1)SA || Hi+1

OK or DenyOK or Deny

Target APi+1

May 2006

Sood, Walker, ZhaoSlide 10

doc.: IEEE 802.11-06/0623r0

Submission

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 Hn randomly and let C be the AzS challenge value. Then defineHn–1 = SHA-256(Hn || C)

Hn–2 = SHA-256(Hn–1 || C)

…

H0 = SHA-256(H1 || C)

May 2006

Sood, Walker, ZhaoSlide 11

doc.: IEEE 802.11-06/0623r0

Submission

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

May 2006

Sood, Walker, ZhaoSlide 12

doc.: IEEE 802.11-06/0623r0

Submission

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

May 2006

Sood, Walker, ZhaoSlide 13

doc.: IEEE 802.11-06/0623r0

Submission

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

May 2006

Sood, Walker, ZhaoSlide 14

doc.: IEEE 802.11-06/0623r0

Submission

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 H3 before transaction of H2 is completed, then H2 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

May 2006

Sood, Walker, ZhaoSlide 15

doc.: IEEE 802.11-06/0623r0

Submission

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.

May 2006

Sood, Walker, ZhaoSlide 16

doc.: IEEE 802.11-06/0623r0

Submission

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…

May 2006

Sood, Walker, ZhaoSlide 17

doc.: IEEE 802.11-06/0623r0

Submission

Straw Poll

Would you like normative text for this mechanism submitted for inclusion into the TGr draft?

Yes:

No:

May 2006

Sood, Walker, ZhaoSlide 18

doc.: IEEE 802.11-06/0623r0

Submission

Discussion?