Doc.: IEEE 802.11-05/1063r0 Submission Nov 2005 Jon Edney, NokiaSlide 1 The Lock-out Problem - an Analysis Notice: This document has been prepared to assist.

Slides:



Advertisements
Similar presentations
Doc.: IEEE /1007r0 Submission September 2005 Fred Haisch, Proxim WirelessSlide 1 Alternative Lock-up Solution Notice: This document has been prepared.
Advertisements

Doc.: IEEE /0256r0 Submission February 2007 A. Centonza, D. StephensonSlide 1 Limitations on the Use of EBR Notice: This document has been prepared.
Doc.: IEEE /0866r1 Submission September 2005 Michael Montemurro, Chantry NetworksSlide 1 Mobility Domain Definition and Description Notice: This.
Doc.: IEEE /90r0 Submission Nov., 2012 NICTSlide b NICT Proposal IEEE P Wireless RANs Date: Authors: Notice: This document.
Doc.: IEEE /0930r0 Submission July 2006 Nancy Cam-Winget, Cisco Slide 1 Editor Updates since Jacksonville Notice: This document has been prepared.
Doc.: IEEE /1867r1 Submission November r Security TeamSlide 1 TGr Security Requirements Notice: This document has been prepared to.
Doc.: IEEE /0094r0 Submission November 2009 Steve Shellhammer, QualcommSlide 1 Comments on PAR Notice: This document has been prepared.
Doc.: IEEE /0358r0 Submission March 2007 Zhao and Walker, Intel CorpSlide 1 Thoughts on Peer Capacity Date: Authors: Notice: This document.
Doc.: IEEE /1138r0 Submission November 2005 Cheng Hong, PanasonicSlide 1 Authorization Information in interworking Notice: This document has been.
Doc.: IEEE /0121r0 Submission January 2006 S. Bezzateev, A. Fomin, M. WongSlide 1 Broadcast Management Frame Protection Notice: This document.
Doc.: IEEE /0644r2 Submission May 2006 Päivi Ruuska, NokiaSlide 1 Measurement Pilot Transmission Information as optional information in Probe.
Doc.: IEEE /1807r2 Submission November 2006 Matthew Fischer (Broadcom)Slide 1 TGN adhoc MAC subgroup report for November 2006 Notice: This document.
Doc.: IEEE /2237r0 Submission July 2007 Emily Qi, Intel CorporationSlide 1 TGv Redline D1.0 Insert and Deletion Notice: This document has been.
Doc.: IEEE /0072r0 Submission January 2009 Slide 1 Proxy ARP Issue for Direct Link Setup Notice: This document has been prepared to assist IEEE.
Doc.: IEEE /1212r0 Submission TGT and MEF Liaison Notice: This document has been prepared to assist IEEE It is offered as a basis for.
Doc.: IEEE /86r2 Submission March, 2010 Gabor BajkoSlide 1 Location Proxy Notice: This document has been prepared to assist IEEE It is.
Doc.: IEEE /0667r0 Submission July 2005 Mike Moreton, STMicroelectronicsSlide 1 Multiple Networks Notice: This document has been prepared to assist.
Doc.: IEEE /0028r0 Submission January 2005 Eleanor Hepworth, Siemens Roke ManorSlide 1 Definitions and Terminology Notice: This document has been.
Doc.: IEEE /0197r0 Submission March 2005 Nancy Cam-Winget et alSlide 1 TAP & JIT Merge Process Notice: This document has been prepared to assist.
Doc.: IEEE /01097r0 Submission November 2005 N. Cam-Winget, K. Sood, and J. WalkerSlide 1 EAPKIE Replay Counters and MIC Notice: This document.
Doc.: IEEE /1006r0 Submission September 2005 Andrew McDonald, Siemens Roke ManorSlide 1 Initial Network Selection Concept Notice: This document.
Doc.: IEEE /0215r1 Submission January 2006 Jesse Walker, Intel CorporationSlide 1 TGw Closing Report Notice: This document has been prepared to.
Doc.: IEEE /0652r1 Submission May 2007 Emily Qi, Intel CorporationSlide 1 TGv Redline D0.12 Insert and Deletion Notice: This document has been.
LB84 General AdHoc Group Sept. Closing TGn Motions
[ Interim Meetings 2006] Date: Authors: July 2005
IEEE White Space Radio Contribution Title
LB73 Noise and Location Categories
LB73 Noise and Location Categories
Waveform Generator Source Code
March 2014 Election Results
TGp Closing Report Date: Authors: July 2007 Month Year
Attendance and Documentation for the March 2007 Plenary
3GPP Extended Date: Authors: July 2005 July 2005
[ Policies and Procedure Summary]
3GPP liaison report May 2006 May 2006 Date: Authors:
Motion to accept Draft p 2.0
Protected SSIDs Date: Authors: March 2005 March 2005
3GPP liaison report July 2006
[place presentation subject title text here]
(Presentation name) For (Name of group) (Presenter’s name,title)
On Coexistence Mechanisms
TGu-changes-from-d0-02-to-d0-03
TGp Closing Report Date: Authors: May 2007 Month Year
On Coexistence Mechanisms
Reflector Tutorial Date: Authors: July 2006 Month Year
TGv Redline D0.07 Insert and Deletion
TGv Redline D0.06 Insert and Deletion
ADS Study Group Mid-week Report
IEEE P Wireless RANs Date:
Protection Assurance Method
TGu-changes-from-d0-01-to-d0-02
LB73 Noise and Location Categories
TGy draft 2.0 with changebars from draft 1.0
TGv Redline D0.10 Insert and Deletion
WAPI Position Paper Sept 2005 Sept 2005 IEEE WG
Redline of draft P802.11w D2.2 Date: Authors:
TGu-changes-from-d0-02-to-d0-03
[ Policies and Procedure Summary]
Beamforming and Link Adaptation Motions
Draft P802.11s D1.03 WordConversion
Questions to the Contention-based Protocol (CBP) Study Group
Motion to go to Letter Ballot
EC Motions – July 2005 Plenary
TGu-changes-from-d0-04-to-d0-05
Method for geting Link RCPI
Transition Nowhere Date: Authors: Sept 2005 Sept 2005
TGu-changes-from-d0-03-to-d0-04
TGu Motions Date: Authors: May 2006 May 2006
WAPI Position Paper Sept 2005 Sept 2005 IEEE WG
Use of KCK for TGr Management Frame Protection
Presentation transcript:

doc.: IEEE /1063r0 Submission Nov 2005 Jon Edney, NokiaSlide 1 The Lock-out Problem - an Analysis 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, 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. Date: Authors:

doc.: IEEE /1063r0 Submission Nov 2005 Jon Edney, NokiaSlide 2 Abstract This submission considers possible responses that an AP might make when presented with unprotected management frames such as associate request and open Authenticate while a valid security association is in place. The consequences of accepting the messages is analysed showing a number of problems that are introduced. The alternative strategy of ignoring such messages prevents a station from rejoining a network if key state is lost. This is “the lock-out problem”

doc.: IEEE /1063r0 Submission Nov 2005 Jon Edney, NokiaSlide 3 The difficult question If AP has an authenticated station ‘X’.... and it receives an (unprotected) association request from station claiming to be ‘X’.... Should it: (a) Ignore the request (b) Fail the request (c) accept the request If the answer is (a) or (b) then we have a lockout problem since a station that loses its key state cannot rejoin the network. Let’s explore the consequences of answer (c)

doc.: IEEE /1063r0 Submission Nov 2005 Jon Edney, NokiaSlide 4 Answer ‘C’: accept association The idea is to enable the existing authenticated station to continue un-interrupted while allowing the new station to complete the authentication phase. If the new station succeeds, the state for the existing connection will be deleted. AP XX Association AP XX Authenticating (802.1X) AP XX Authenticated existingnew

doc.: IEEE /1063r0 Submission Nov 2005 Jon Edney, NokiaSlide 5 Can Answer ‘C’ really work? Requires maintaining state for two stations with the same MAC address - differentiated by context Requires de-multiplexing incoming messages to deliver to the correct instance of the station - even though destination address is the same!

doc.: IEEE /1063r0 Submission Nov 2005 Jon Edney, NokiaSlide 6 Analysis Consider an attack where: –STA ‘X’ is authenticated and protected –STA ‘Z’ is attacker using MAC address of ‘X’ AP XZ Forges messages from ‘X’ AP can only see one STA ‘X’

doc.: IEEE /1063r0 Submission Nov 2005 Jon Edney, NokiaSlide 7 AP Multi-State AP receives unprotected messages that are inappropriate for a protected station: –open authenticate –associate request AP assumes this is caused by either: –STA ‘X’ that has lost it’s key state, or... –A forgery attempt by unknown STA AP decides to accept unprotected messages from “aspirant station” pending authentication This means: –New entry in STA table but with same MAC address as an existing entry –New 802.1X port and authenticator - but with same MAC address as existing port. Old port is closed, new port is open –MAC state very confused because of possible sequence number errors. Mayhem if one is in power save mode and the other not!

doc.: IEEE /1063r0 Submission Nov 2005 Jon Edney, NokiaSlide 8 Message Flow Data messages continue to flow through original 802.1X port and be protected and transmitted. But.. Both STAs are associated so both will receive the frames and ACK them. Therefore high chance of ACK collision preventing frame delivery Inbound data frames from new connection will not be delivered because they are not encrypted Therefore new station cannot get EAPOL frames delivered to its instance of authenticator. Cannot proceed. Suppose we special case to allow unprotected EAPOL frames to be delivered to appropriate authenticator....

doc.: IEEE /1063r0 Submission Nov 2005 Jon Edney, NokiaSlide 9 4-Way Handshake Authenticator for “new” station generates the first message of 4-way handshake. But it will be received by both the real STA ‘X’ and the bogus STA ‘Y’. STA ‘X’ may reject due to non- protection. STA may complete the 4-way handshake multiplexing messages based on the protection status of the messages Big problems if real STA X decides to rekey at the same time.

doc.: IEEE /1063r0 Submission Nov 2005 Jon Edney, NokiaSlide 10 Conclusion Accepting “second” parallel association has negative consequences: a) MAC ACK collisions b) Failure of protocol at MAC level c) Inability to deliver EAPOL frames (without special handling) d) Architectural changes: need to index station table by both MAC address and context Recommendation that any unprotected association requests should be discarded while security association exists.

doc.: IEEE /1063r0 Submission Nov 2005 Jon Edney, NokiaSlide 11 Consequence If unprotected association request is discarded then it is necessary to find a solution for the case where a STA loses key state and cannot re-join the network

doc.: IEEE /1063r0 Submission Nov 2005 Jon Edney, NokiaSlide 12 References w-partial-proposal-amid.ppt