150 likes | 288 Views
Discussion on the proposal to start a new Security SG in 802.11 WG. The 802.11 WG should not start a new security SG at this time without a more compelling case. 09/315r1 suggests that a new 802.11 SG is required to consider specific security issues
E N D
Discussion on the proposal to starta new Security SG in 802.11 WG Myles et al (Cisco)
The 802.11 WG should not start a new security SG at this time without a more compelling case • 09/315r1 suggests that a new 802.11 SG is required to consider specific security issues • Tough economic times means 802.11 WG should focus on only starting work that is “compelling” • There is no compelling case for any of the work suggested for a new SG to be investigated any further: • Consideration of GCM & SIV as new 802.11 ciphers should wait for 802.11ad requirements & progress • The assumptions behind the suggestion for a new decentralized authentication mechanism are flawed • Location services are probably better protected at the application layer Myles et al (Cisco)
09/315r1 suggests that a new 802.11 SG is required to consider specific security issues • 09/315r1 suggests a SG and subsequent TG would consider: • Secure, de-centralized authentication and key management • These solutions should be suitable for a traditional ESS as well as ad hoc, mesh, and various peer-to-peer applications. • A password-based key exchange resistant to passive attack, active attack and dictionary attack. • A certificate-based key exchange • Definition (not development) of new ciphers • AES-GCM: a high-performance, single-pass, cipher for authenticated encryption • AES-SIV: a misuse-resistant cipher for authenticated encryption • Solution to current problems that are outside the scope of existing TG’s • TGv’s location services Myles et al (Cisco)
Tough economic times means 802.11 WG should focus on only starting work that is “compelling” • The world is currently experiencing difficult economic times, which has meant many companies have limited their standards development activities • A number of experts have are no longer available to the 802.11 WG • Travel to meetings has been restricted by many companies • Evidence of these constraints include: • The declining number of participants in the WG despite a large number on important ongoing activities • TGmb, TGn, TGp, TGs, TGu, TGv, TGw, TGz, TGaa, TGac, TGad • The difficulty various TGs have experienced recently filling officer positions; there are a half dozen open positions across the 802.11 WG • This suggests that the WG should have a discipline of only starting a TG on activities that are truly compelling • This is particularly true for security topics given the rarity of available real security experts • Even the “bar” for starting a SG should be relatively high given the historical difficulty of stopping an activity once it has started in the 802.11 WG Myles et al (Cisco)
Consideration of GCM as a new 802.11 cipher should wait for 802.11ac/ad requirements & progress • 09/315 suggests that GCM should be considered as an option in 802.11 in addition to the existing CCMP cipher • Like CCM, GCM performs authenticated encryption and accepts additional authenticated data. • GCM performs authenticated encryption with one pass over the data. This allows for much higher throughput that CCM which requires two passes • However, none of the reasons given for the introduction of GCM are compelling, particularly in a “legacy” 802.11a/b/g/n environment • The consideration of the introduction of GCM or some other cipher should be held off until the requirements and progress of 802.11ad is better known • It may make sense to incorporate GCM into 802.11ad at the appropriate time Myles et al (Cisco)
None of the reasons given for the introduction of GCM are compelling Myles et al (Cisco)
None of the reasons given for the introduction of GCM are compelling Myles et al (Cisco)
Consideration of SIV as a new 802.11 cipher should wait for 802.11ac/ad requirements & progress • 09/315 suggests that SIV should be considered as an option in 802.11 in addition to the existing CCMP cipher • Like CCM, SIV performs authenticated encryption and accepts additional authenticated data. • Unlike CCM, SIV will not lose all security if a nonce/counter is reused. This allows for more robust security, especially when the operations are taking place in software or in situations where uniqueness of counters cannot be strictly guaranteed. • However, none of the reasons given for the introduction of SIV are compelling, particularly in a “legacy” 802.11a/b/g/n environment • The consideration of the introduction of SIV or some other cipher should be held off until the requirements and progress of 802.11ac and 802.11ad are better known Myles et al (Cisco)
None of the reasons given for the introduction of SIV are compelling Myles et al (Cisco)
The assumptions behind the suggestion for a new decentralized authentication mechanism are flawed • 09/315 suggests that work is required to define new decentralized authentication mechanism • Each device has its own authentication credential, a password or a certificate. • Each device can authenticate another device without external assistance. • Examples • The password-authenticated key exchange in 802.11s: SAE. • SKEME, a certificate-based authenticated key exchange protocol • DHKE-1, a certificate-based authenticated key exchange protocol • However, none of the reasons given for the introduction of such a new decentralized authentication mechanism are compelling, particularly as such authentication methods already exist • There is no need for the 802.11 WG to consider new decentralized authentication mechanism, beyond properly reviewing SAE in 802.11 TGs Myles et al (Cisco)
None of the reasons for the introduction of a new decentralized authentication mechanism are compelling Myles et al (Cisco)
None of the reasons for the introduction of a new decentralized authentication mechanism are compelling Myles et al (Cisco)
Location services are better protected at the application layer • 09/315 suggests that work is required to define security for location services outside the scope of TGv • A STA wants to protect announcements it sends out pertaining to its location and these announcements are be received by multiple APs, some of which the STA does not share an active security association. • However, none of the (few) reasons given for the protection of location services are compelling • It is arguable that location services are better protected at the application layer Myles et al (Cisco)
None of the reasons for the protection of location messages are compelling Myles et al (Cisco)
The 802.11 WG should not start a new security SG at this time without a more compelling case • But what should we do next? • GCM/SIV • Incorporate into 802.11ad at the appropriate time – probably 1-2 years hence • Decentralised authentication method • Do nothing until users are found that want this feature • Location protection • Do nothing until users are found that want this feature Myles et al (Cisco)