Скачать презентацию May 09 doc IEEE 802 11 -09 0580 Скачать презентацию May 09 doc IEEE 802 11 -09 0580

705f098d0e0acbaab2e011fb7e669bb6.ppt

  • Количество слайдов: 15

May 09 doc. : IEEE 802. 11 -09/0580 r 0 Discussion on the proposal May 09 doc. : IEEE 802. 11 -09/0580 r 0 Discussion on the proposal to start a new Security SG in 802. 11 WG Submission 1 Myles et al (Cisco)

May 09 doc. : IEEE 802. 11 -09/0580 r 0 The 802. 11 WG May 09 doc. : IEEE 802. 11 -09/0580 r 0 The 802. 11 WG should not start a new security SG at this time without a more compelling case • 09/315 r 1 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. 11 ad 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 Submission 2 Myles et al (Cisco)

May 09 doc. : IEEE 802. 11 -09/0580 r 0 09/315 r 1 suggests May 09 doc. : IEEE 802. 11 -09/0580 r 0 09/315 r 1 suggests that a new 802. 11 SG is required to consider specific security issues 09/315 r 1 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 Submission 3 Myles et al (Cisco)

May 09 doc. : IEEE 802. 11 -09/0580 r 0 Tough economic times means May 09 doc. : IEEE 802. 11 -09/0580 r 0 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 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 Submission 4 Myles et al (Cisco)

May 09 doc. : IEEE 802. 11 -09/0580 r 0 Consideration of GCM as May 09 doc. : IEEE 802. 11 -09/0580 r 0 Consideration of GCM as a new 802. 11 cipher should wait for 802. 11 ac/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. 11 a/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. 11 ad is better known – It may make sense to incorporate GCM into 802. 11 ad at the appropriate time Submission 5 Myles et al (Cisco)

May 09 doc. : IEEE 802. 11 -09/0580 r 0 None of the reasons May 09 doc. : IEEE 802. 11 -09/0580 r 0 None of the reasons given for the introduction of GCM are compelling Reason for GCM Counter Compelling? GCM is a very fast cipher • CCM is sufficiently fast for 802. 11 a/b/g/n and so GCM provides no benefit in this case • GCM might be required to support 802. 11 ac or 802. 11 ad in the future. However, these amendments are many years from completion. Any work to provide a new cipher can wait until requirements have been better established and more progress made. GCM could be incorporated directly into these TGs GCM uses fewer gates than CCM when implemented in hardware • It is true that GCM can be implemented in fewer gates than CCM. However, the introduction of GCM into 802. 11 a/b/g/n means that implementations will need to support both GCM and CCM, with a corresponding increase in the gate count GCM uses less power than CMMP when implemented in hardware • It is probably true that GCM uses less power than CCM; claims of ~30% less power seem to be accepted by many experts. However, the cipher is only a small part of the overall power budget in a typical device and so the power benefit of GCM over CCM is relatively small Submission 6 Myles et al (Cisco)

May 09 doc. : IEEE 802. 11 -09/0580 r 0 None of the reasons May 09 doc. : IEEE 802. 11 -09/0580 r 0 None of the reasons given for the introduction of GCM are compelling Reason for GCM Counter Compelling? • It may be true that GCM can be implemented in software. However, this is probably not relevant to the market given most 802. 11 implementations now have CCM implemented in hardware - • Devices that support GCM for 802. 11 a/b/g/n will also need to support “legacy” CCM devices. There is a significant “tax” to build, test and certify multi cipher devices in mixed environments - • Devices that support GCM for 802. 11 a/b/g/n will also need to support “legacy” CCM devices. There is a significant “tax” to explain to users why they should use one or the other, particularly as GCM provides no security benefit to all users - • No problem (except maybe 802. 11 ac/ad) has been identified for which GCM is a solution and CCM is unacceptable GCM is efficient enough to be implemented in software Submission 7 Myles et al (Cisco)

May 09 doc. : IEEE 802. 11 -09/0580 r 0 Consideration of SIV as May 09 doc. : IEEE 802. 11 -09/0580 r 0 Consideration of SIV as a new 802. 11 cipher should wait for 802. 11 ac/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. 11 a/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. 11 ac and 802. 11 ad are better known Submission 8 Myles et al (Cisco)

May 09 doc. : IEEE 802. 11 -09/0580 r 0 None of the reasons May 09 doc. : IEEE 802. 11 -09/0580 r 0 None of the reasons given for the introduction of SIV are compelling Reason for SIV Counter Compelling? SIV is more robust than CCM because security is maintained even if the nonce/counter is reused • CCM has a construction whereby the possibility of nonce/counter reuse is mitigated, which is clearly satisfactory in today’s deployments SIV is more secure than both GCM and CCM • It is unclear in what respect SIV is more secure than either CCM or GCM - • All of the other arguments against GCM as an additional cipher for 802. 11 a/b/g/n systems seem to apply to SIV Submission 9 Myles et al (Cisco)

May 09 doc. : IEEE 802. 11 -09/0580 r 0 The assumptions behind the May 09 doc. : IEEE 802. 11 -09/0580 r 0 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. 11 s: 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 Submission 10 Myles et al (Cisco)

May 09 doc. : IEEE 802. 11 -09/0580 r 0 None of the reasons May 09 doc. : IEEE 802. 11 -09/0580 r 0 None of the reasons for the introduction of a new decentralized authentication mechanism are compelling Reason for secure, decentralized authentication Counter Compelling? Existing methods require a centralized RADIUS sever • Neither EAP nor 802. 1 X require a centralized RADIUS sever. Algorithms such as EAP-TLS, EAP-GPSK, EAP-FAST, EAPTTLS, PEAP, etc. are not centralized authentication algorithms. They are often deployed in a centralized server because this makes them manageable, but there is nothing fundamental in any of the protocols that makes them centralized. The only well known EAP methods that are centralized are EAP-SIM and EAP -AKA, which require communication with a service provider HLR/HSS Au. C. - • Many of the pee to peer security problems are not because the security mechanisms don't exist or require EAP. Peer-to-peer proponents typically trade off security for usability. Its not clear that new mechanisms would result in a significant improvement in security or peer to peer deployability. Submission 11 Myles et al (Cisco)

May 09 doc. : IEEE 802. 11 -09/0580 r 0 None of the reasons May 09 doc. : IEEE 802. 11 -09/0580 r 0 None of the reasons for the introduction of a new decentralized authentication mechanism are compelling Reason for secure, decentralized authentication A de-centralized authentication method using certificates is required A de-centralized authentication method using preshares keys is required Submission Counter Compelling? • There already is a certificate based EAP method that is standardized (EAP-TLS). This can be implemented without a RADIUS server. There are products that do this today • There is no reason that an EAP method cannot be made to support pre-shared key. • The current draft of 802. 11 s contains SAE, which appears to satisfy this requirement; it is not clear why a SG to study yet another solution is required. It might be more useful for the WG to properly review SAE 12 Myles et al (Cisco)

May 09 doc. : IEEE 802. 11 -09/0580 r 0 Location services are better May 09 doc. : IEEE 802. 11 -09/0580 r 0 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 Submission 13 Myles et al (Cisco)

May 09 doc. : IEEE 802. 11 -09/0580 r 0 None of the reasons May 09 doc. : IEEE 802. 11 -09/0580 r 0 None of the reasons for the protection of location messages are compelling Reason for secure location services Protect location announcements from STA to multiple APs Counter Compelling? • It is true that location announcements need protection because without a mechanism to validate authenticity of the messages a smart thief could send fake location notification messages to confuse the location server trying to determine location of a device based on those transmissions. • However, the proposal to protect these frames at layer 2 does not consider the option of solving the problem at the application layer • Many believe it is better to establish a security context between the entity determining location (i. e. location server) and the devices being tracked rather than having security context between each individual AP and the devices being tracked • There appear to have been no requests from users for functionality at layer 2 – if there are requests then they need to provide threat models and use cases Submission 14 Myles et al (Cisco)

May 09 doc. : IEEE 802. 11 -09/0580 r 0 The 802. 11 WG May 09 doc. : IEEE 802. 11 -09/0580 r 0 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. 11 ad 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 Submission 15 Myles et al (Cisco)