1. 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 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: 2005-11-03 Authors:

2. doc.: IEEE 802.11-05/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”

3. doc.: IEEE 802.11-05/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)

4. doc.: IEEE 802.11-05/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

5. doc.: IEEE 802.11-05/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!

6. doc.: IEEE 802.11-05/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’

7. doc.: IEEE 802.11-05/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!

8. doc.: IEEE 802.11-05/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....

9. doc.: IEEE 802.11-05/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.

10. doc.: IEEE 802.11-05/1063r0 Submission Nov 2005 Jon Edney, NokiaSlide 10 Conclusion Accepting “second” parallel association has negative consequences: a) MAC ACK collisions b) Failure of 802.11 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.

11. doc.: IEEE 802.11-05/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

12. doc.: IEEE 802.11-05/1063r0 Submission Nov 2005 Jon Edney, NokiaSlide 12 References 11-05-0901-00-000w-partial-proposal-amid.ppt