1. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré Requirements for Management Frame Protection Schemes Fabrice Stevens, Sébastien Duré France Telecom March 2005

2. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré Objectives of this talk First step in the definition of ADS protection schemes requirements Help refine the scope of the work Raise discussion on the security needs for specific MF

3. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré Outline Overall design goals Security Requirements Some known attacks… First analysis of specific management frames needs

4. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré Overall design goals Common basics –Support for legacy devices –Low upgrading costs –And on and on…

5. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré Overall design goals 802.11 specific –Not to reinvent nor replace 802.11i! –Pre 802.11i authentication? Post 802.11i authentication? 802 11i solves half of the ADS problem But a lot of frames are sent before the authentication … Security implications… –Applicable to IBSS or not? –Handle both unicast and broadcast management frames?

6. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré Overall design goals 802.11 specific –Adaptable to future management frames? PAR says "selected management frames"… –Per-IE protection? Per MF? Maybe a different answer for each service (DOA, Confidentiality) How much are we willing to pay? –Performance, architecture costs…

7. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré Security Requirements Dimensions mentioned in the PAR –Data origin authentication –Data integrity (provided by data origin authentication) –Confidentiality –Replay-protection

8. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré Data origin authentication (1/3) Management Frames can go both ways… –Uplink MF (STA  AP) –Downlink MF (AP  STA) Some MF can be sent by APs and STAs… Whose MF need to be authenticated? –the APs'? the clients'? both? –Protecting APs' MF still leaves some known DoS attacks from the clients To make it harder… –We might want any client to be able to use our network –We certainly do not want clients to connect to a rogue AP

9. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré Data origin authentication (2/3) "State of the Art" –Pre 802.11i authentication No authentication of any entity (!) –Post 802.11i authentication Client is authenticated But EAP currently provides no explicit AP authentication Limited changes to the specs could provide what we need…

10. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré Data origin authentication (3/3) If we limit ourselves to a post-802.11i authentication protection scheme –Should we provide "better" authentication than 802.11i? –Should we assume that EAP methods will bring explicit AP authentication? see IETF Draft draft-arkko-eap-service-identity- auth-01.txt –Is it just fine the way it is?

11. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré Confidentiality Do we care? –Location Configuration Information in.11k? –STA statistics? Will we care? (out-of scope question?) What do we want to protect? –each IE –the entire MF (probably much more efficient)

12. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré Replay protection Estimation of the potential damage? –Desassociation and deauthentication frames Could be troublesome –Ressource measurement action frames Could be troublesome too –… see the table in the following slides for the others

13. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré Summary of MF protection scheme requirements MandatoryRecommendedOptional post-802.11i capableX pre-802.11i capable X applicable to IBSS X protect unicast framesX protect broadcast frames X adaptable to future MFX per-IE protection X entire MF protectionX AP --> STA MF authenticationX STA --> AP MF authenticationX resistance to replayX confidentialityX Note: these are requirements for proposals, not for protection policies…

14. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré Some known attacks using MF… Denial of Service –Disassociation/Deauthentication frames: trivial DoS (management frame) –Association Requests flooding (management frame) –Duration field (all 802.11 frames) Man-in-the-Middle –MF spoofing Session hijacking –(assuming there is no 802.11i auth…)  Most attacks exploit unauthenticated frames ，

15. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré Threats What are today's most important threats? –DoS? Keep in mind that we'll never protect DoS due to radio jamming… But deauth/deassoc make it trivial –MITM? Assumes that there was no 802.11i auth Still applicable to most hotspots… –Session-hijacking? Same as MITM –Others? What are the threats brought by 11e and 11k?

16. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré First thoughts on specific MF needs (How) should we define the security requirements? –Mandate minimal security services for each type of MF –Recommend some others –Define the remaining ones as optional Put another way: should we enforce a minimum security policy when 802.11w is used? –And trying to avoid downgrading attacks… In the following, we consider MF for infrastructure BSS…

17. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré Needs for standard 802.11 MF Frame sourceDOAconfidentiality replay protection APClient beaconX ROR probe req XOO- authentication STA->AP XOO- (re)assoc req XOO- probe respX ROR authentication AP->STAX ROR (re)assoc respX ROR disassocXXMOM deauthXXMOM

18. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré Needs for 802.11k frames Frame DOAConfidentialityNon-replay measurement requestOO- measurement reportROR link measurement requestOO- link measurement reportROR neighbor report requestOO- neighbor report responseROR measurement requests and reports: channel load, noise histogram, beacon, frame, hidden node, medium sensing time histogram, STA statistics, location configuration information, measurement pause

19. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré Needs for 802.11e frames Frame DOAConfidentialityNon Replay QoS ADDTS ReqMOM ADDTS RespMOM DELTSMOM ScheduleROR DLS DLS ReqRO- DLS RespROR DLS teardownROR Block Ack ADDBA ReqOO- ADDBA RespOOO DELBAOOO

20. doc.: IEEE 802.11-05/0237r0 Submission March 2005 Fabrice Stevens, Sébastien Duré What next? Need to better analyze the threats we're facing Continue the discussions In the end, come up with one or more documents including –Requirements for ADS protection scheme proposals –Selection criteria Potentially using the list of known attacks (that has yet to be completed), and the list of recommended/optional requirements for the protection schemes –Description of the minimum security policy for MF Or recommended practice?