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

doc.: IEEE /0580r0 Submission May 09 Myles et al (Cisco)Slide 2 The WG should not start a new security SG at this time without a more compelling case 09/315r1 suggests that a new SG is required to consider specific security issues Tough economic times means 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 ciphers should wait for 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

doc.: IEEE /0580r0 Submission May 09 Myles et al (Cisco)Slide 3 09/315r1 suggests that a new 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

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

doc.: IEEE /0580r0 Submission May 09 Myles et al (Cisco)Slide 5 Consideration of GCM as a new cipher should wait for ac/ad requirements & progress 09/315 suggests that GCM should be considered as an option in 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” 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 ad is better known –It may make sense to incorporate GCM into ad at the appropriate time

doc.: IEEE /0580r0 Submission May 09 Myles et al (Cisco)Slide 6 None of the reasons given for the introduction of GCM are compelling Reason for GCMCounterCompelling? GCM is a very fast cipher CCM is sufficiently fast for for a/b/g/n and so GCM provides no benefit in this case GCM might be required to support ac or 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 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 

doc.: IEEE /0580r0 Submission May 09 Myles et al (Cisco)Slide 7 None of the reasons given for the introduction of GCM are compelling Reason for GCMCounterCompelling? GCM is efficient enough to be implemented in software It may be true that GCM can be implemented in software. However, this is probably not relevant to the market given most implementations now have CCM implemented in hardware  -Devices that support GCM for 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 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 ac/ad) has been identified for which GCM is a solution and CCM is unacceptable 

doc.: IEEE /0580r0 Submission May 09 Myles et al (Cisco)Slide 8 Consideration of SIV as a new cipher should wait for ac/ad requirements & progress 09/315 suggests that SIV should be considered as an option in 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” 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 ac and ad are better known

doc.: IEEE /0580r0 Submission May 09 Myles et al (Cisco)Slide 9 None of the reasons given for the introduction of SIV are compelling Reason for SIVCounterCompelling? 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 a/b/g/n systems seem to apply to SIV 

doc.: IEEE /0580r0 Submission May 09 Myles et al (Cisco)Slide 10 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 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 WG to consider new decentralized authentication mechanism, beyond properly reviewing SAE in TGs

doc.: IEEE /0580r0 Submission May 09 Myles et al (Cisco)Slide 11 None of the reasons for the introduction of a new decentralized authentication mechanism are compelling Reason for secure, decentralized authentication CounterCompelling? Existing methods require a centralized RADIUS sever Neither EAP nor 802.1X require a centralized RADIUS sever. Algorithms such as EAP-TLS, EAP-GPSK, EAP-FAST, EAP- TTLS, 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 AuC.  -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. 

doc.: IEEE /0580r0 Submission May 09 Myles et al (Cisco)Slide 12 None of the reasons for the introduction of a new decentralized authentication mechanism are compelling Reason for secure, decentralized authentication CounterCompelling? A de-centralized authentication method using certificates is required 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  A de-centralized authentication method using pre- shares keys is required There is no reason that an EAP method cannot be made to support pre-shared key. The current draft of 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 

doc.: IEEE /0580r0 Submission May 09 Myles et al (Cisco)Slide 13 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

doc.: IEEE /0580r0 Submission May 09 Myles et al (Cisco)Slide 14 None of the reasons for the protection of location messages are compelling Reason for secure location services CounterCompelling? Protect location announcements from STA to multiple APs 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 

doc.: IEEE /0580r0 Submission May 09 Myles et al (Cisco)Slide 15 The 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 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