May 09

Myles et al (Cisco)

Slide 1

doc.: IEEE 802.11-09/0580r0

Submission

Discussion on the proposal to starta new Security SG in 802.11 WG

Name Affiliations email

Andrew Myles Cisco andew.myles@cisco.com

Nancy Winget Cisco ncamwing@cisco.com

Joe Salowey Cisco jsalowey@cisco.com

May 09

Myles et al (Cisco)

Slide 2

doc.: IEEE 802.11-09/0580r0

Submission

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

May 09

Myles et al (Cisco)

Slide 3

doc.: IEEE 802.11-09/0580r0

Submission

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

May 09

Myles et al (Cisco)

Slide 4

doc.: IEEE 802.11-09/0580r0

Submission

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

May 09

Myles et al (Cisco)

Slide 5

doc.: IEEE 802.11-09/0580r0

Submission

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

May 09

Myles et al (Cisco)

Slide 6

doc.: IEEE 802.11-09/0580r0

Submission

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 for 802.11a/b/g/n and so GCM provides no benefit in this case

• GCM might be required to support 802.11ac or 802.11ad 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.11a/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

May 09

Myles et al (Cisco)

Slide 7

doc.: IEEE 802.11-09/0580r0

Submission

None of the reasons given for the introduction of GCM are compelling

Reason for GCM Counter Compelling?

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 802.11 implementations now have CCM implemented in hardware

- • Devices that support GCM for 802.11a/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.11a/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.11ac/ad) has been identified for which GCM is a solution and CCM is unacceptable

May 09

Myles et al (Cisco)

Slide 8

doc.: IEEE 802.11-09/0580r0

Submission

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

May 09

Myles et al (Cisco)

Slide 9

doc.: IEEE 802.11-09/0580r0

Submission

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.11a/b/g/n systems seem to apply to SIV

May 09

Myles et al (Cisco)

Slide 10

doc.: IEEE 802.11-09/0580r0

Submission

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

May 09

Myles et al (Cisco)

Slide 11

doc.: IEEE 802.11-09/0580r0

Submission

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.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.

May 09

Myles et al (Cisco)

Slide 12

doc.: IEEE 802.11-09/0580r0

Submission

None of the reasons for the introduction of a new decentralized authentication mechanism are compelling

Reason for secure, decentralized authentication

Counter Compelling?

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 802.11s 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

May 09

Myles et al (Cisco)

Slide 13

doc.: IEEE 802.11-09/0580r0

Submission

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

May 09

Myles et al (Cisco)

Slide 14

doc.: IEEE 802.11-09/0580r0

Submission

None of the reasons for the protection of location messages are compelling

Reason for secure location services

Counter Compelling?

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

May 09

Myles et al (Cisco)

Slide 15

doc.: IEEE 802.11-09/0580r0

Submission

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