doc.: ieee 802.11-06/0623r0 submission may 2006 sood, walker, zhaoslide 1 a method to protect tgr...
Post on 13-Dec-2015
218 Views
Preview:
TRANSCRIPT
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?
top related