IEEE 802.11k Security: A Conceptual Model

1
IEEE 802.11k Security A Conceptual Model

• Bernard Aboba
• Microsoft

2
Overview

• Before proposing an appropriate security scheme
  for 802.11k, we need to articulate the threat
  model what we are trying to protect against.
• The primary threats to RRM are bad measurements.
• This is not a classic denial of service attack!
• We also need to understand the deployment
  implications
• Can implemented ciphersuites be reused?
• Can RRM support be retrofit in existing NIC
  drivers?

3
Basic Principles

• Radio Resource Measurement support is orthogonal
  to security.
• RRM can be used with any level of security (even
  open auth)
• RRM support should be easily retrofit on existing
  drivers
• IEEE 802.11k security needs to leverage
  implemented ciphersuites
• Adding ciphersuites creates deployment barriers
• Subtracting ciphersuites lowers security
• Many RRM security issues are not addressed by
  transmission security.
• Measurements are only a hint.
• Bad Measurements cannot be eliminated by
  security, only heuristics.
• IEEE 802.11k implementations need to validate
  measurements whether or not frames are protected
• Just because a measurement is protected doesnt
  mean its correct!

4
Challenges

• Addressing DoS attacks in 802.11k does not lessen
  the vulnerability of 802.11 systems as a whole
• Many DoS threats unaddressed by IEEE 802.11i
• Many IEEE 802.11k DoS attacks cannot be
  eliminated by cryptography, only heuristics

5
Measurements as Hints

• Bad measurements are likely
• Can result from poor calibration, stale data,
  timing errors, etc.
• Robustness is the core requirement, not
  cryptography
• STAs and APs need to be robust against misleading
  measurements
• STAs and APs cannot trust IEEE 802.11k frames,
  even when security is in use.
• Conclusion IEEE 802.11k implementations must not
  assume that frames transmitted securely are
  correct!

6
Bad Measurements Require Heuristics

• Cryptography cannot guarantee accurate
  measurements
• Security services (authentication, integrity,
  confidentiality) only ensure that bad
  measurements are received as sent.
• Threats from bad measurements exist, even after
  security services are implemented
• Replace attacker STA by uncalibrated/poorly
  implemented but authenticated STA and the same
  attacks are possible
• Heuristics needed
• For rubustness, STAs MUST be able to recover from
  reception of incorrect data
• In a good implementation, service is not denied,
  only delayed
• Conclusion security only reduces the quantity of
  802.11k attacks, but does not affect their
  quality.

7
802.11k Useful At Any Security Level

• 802.11k useful at any security level
• Customers want to use 802.11k with Open Auth,
  WEP, TKIP, CCMP, etc.
• Vendors may retrofit 802.11k on legacy NICs or
  APs
• No room in NVRAM for additional ciphersuites
• No additional CPU cycles for security
• Conclusions
• 802.11k should utilize existing security
  mechanisms rather than creating new ones
• 802.11k security cant be mandatory to use.
• 802.11k not the right group to tackle security
  for management/action frames
• Handling action/management frame security in a
  new PAR would allow 802.11k to complete sooner,
  focus on the security threats unique to
  measurement

8
Example The Neighbor Report

• The Neighbor Report data is third hand - APA
  providing the STA with information about APB
• The information is inherently suspect
• Neighbor report entry can become stale APB was a
  neighbor, but was removed for maintenance how
  long before APA removes it?
• Neighbor report entry can be polluted APB was
  (incorrectly) submitted by STA in a Beacon
  Report, APA didnt validate the entry with
  another STA or with its Authorized AP list
  before including APB in the Neighbor Report.
• Neighbor report has limited shelf life its
  only useful prior to scanning.

9
Neighbor Report Robustness

• A STA may choose to ignore part or all of the
  measurements provided
• The STA might validate the neighbor report using
  other mechanisms (active or passive scan)
• The STA might ignore part or all of the neighbor
  report
• A STA MUST be robust against misleading
  information.
• Example A STA should not blacklist APs based
  on the Neighbor Report
• Bad APs are just lower priority, not off
  limits.
• When information in the Neighbor Report conflicts
  with other sources, the other sources (scan,
  4-way handshake, etc.) are definitive.
• Once the STA scans, it behaves the same way it
  would if there were no Neighbor Reort.
• The Neighbor Report has a very short shelf life

10
Deployment Issues

• Separate RRM Security Negotiation
• Requires confirmation in 4-way handshake or the
  security negotiation is insecure.
• Driver needs to pass up RRM security negotiation
  results to operating system to enable
  confirmation
• New OIDs required current WPA2 driver model does
  not support this!
• End result substantial delays until 802.11k can
  be supported
• Cleaner to leverage 802.11i security negotiation
• Legacy driver support
• Many of todays NIC drivers unlikely to be
  modified to support RRM
• Data frame encapsulation enables RRM support to
  be added in the OS
• Enables performance improvements for legacy
  drivers.

11
Data Frame Proposal

• Pros
• No changes to existing security mechanisms.
• RRM uses implemented ciphersuites.
• No modifications to 4-way handshake.
• No additional text in 802.11k specification.
• Compatible with WPA2 driver model.
• Enables sending of RRM frames over the DS in
  future.
• Cons
• Requires allocation of new Ethertype
• Experimental Ethertype used until actual
  Ethertype allocated

12
Feedback?