IEEE 802.11i: A Retrospective

1
IEEE 802.11i A Retrospective

• Bernard Aboba
• Microsoft
• bernarda_at_microsoft.com
• http//www.drizzle.com/aboba/IEEE/
• March 2004

2
Outline

• What was/was not accomplished
• Threat Model
• Performance Model
• Discovery
• EAP methods
• State Machine
• Authenticated Key Management

3
What Was Accomplished

• Cooperation by multiple standards bodies IEEE
  802, IETF, 3GPP, 3GPP2, GSMA, etc.
• New ciphersuites defined TKIP, AES CCMP
• Flexible key management scheme adopted (based on
  EAP)
• Integration with existing network access
  authentication, authorization and accounting
  mechanisms (RADIUS Diameter)
• Widespread vendor support

4
What Is Missing

• Denial of service vulnerabilities partially
  addressed
• No mandatory-to-implement authentication or key
  management scheme
• Vulnerabilities found in proposed authentication
  and key management schemes
• Widespread interoperability, deployment problems
  reported
• Improvements in roaming latency needed
• Proprietary enhancements often needed to fill in
  the holes

5
Threat Model

• IEEE 802.11i does not include an explicit threat
  model
• Result
• Endless discussions of which threats were worth
  addressing.
• No way to know when the specification was done.
• No detailed discussion of DoS vulnerabilities
• TKIP rejected in many mission critical
  applications due to DoS vulnerabilities
• How to do better
• Discuss the threat model early on
• Identify the usage scenarios, draw simple
  pictures
• Distinguish between DoS attacks
• Attacks from afar worse than attacks requiring
  proximity
• Leveraged attacks more serious than unleveraged
  ones
• References
• RFC 3748 (EAP) threat model
• EAP Key Management Framework (work in progress)

6
802.11 Phases - ESS

• Discovery Phase
• STA scans for APs
• Passive (Beacon)
• Active (Probe Request/Response)
• 80-90 of roaming time spent in discovery
• Reauthentication phase
• Authentication occurs prior to association
• If already associated to another AP, STA can
  pre-authenticate to one or more APs
• Reassociation Phase
• STA attempts to associate/reassociate to
  preferred AP

APs
STA
Probe Requests

IAPP
Probe Responses
Discovery
New AP
Re-association Request
Reauthentication/Reassociatation
Re-association Response

IEEE 802.11i security only
4-way handshake
7
Performance Model

• IEEE 802.11i decided that a backward compatible
  cipher (TKIP) was needed, but
• Performance criteria not thought through
• Lead to adoption of low quality MIC (MICHAEL)
  requiring countermeasures
• All the transition issues not considered
• Virtual AP support typically required to allow
  co-existence
• Result
• Countermeasures unacceptable in many mission
  critical applications
• Reasonable performance, higher quality
  (proprietary) MIC widely adopted
• Proprietary alternative shipped even by the
  MICHAEL proponents!
• Many deployments blocked pending release of
  transition functionality
• How to do better
• Think through the required performance and
  hardware implications explicitly
• Think through the transition/deployment model
• Remember that hardware price/performance
  continually improves, standards take longer than
  expected
• Remember that while retrofits are technically
  possible, vendors may implement only on new
  equipment

8
Discovery

• IEEE 802.11i does not secure management or
  control frames
• Beacon/Probe Request/Response frames
• Association/Reassociation/Disassociation/Deauthent
  ication
• Control frames face severe time constraints (ACK
  w/in SIFS)
• Result DoS vulnerabilities
• Power mgmt. attacks on the TIM, Rate attacks,
  attacks on measurement frames, vendor specific
  attributes, etc.
• Result Fixes required after the fact
• Beacon IEs can now (optionally) be included in
  4-way handshake
• IEEE 802.11k now looking to secure measurement
  frames
• How to do better
• Think through the discovery threats beforehand
• Think through the performance model
• Some frame types may not be protectable,
  depending on the required performance

9
.1af Discovery Questions

• What does the discovery exchange look like?
• Which frames are unicast, which are multicast?
• When can discovery frames be sent?
• Before authentication? After authentication?
• Is the information in discovery frames integrity
  protected? If yes, then
• Is the whole frame protected? Or just individual
  Information Elements?
• Is information protected when sent?
• With group or unicast keys?
• Or is the information protected after the fact?
• With group/unicast keys?
• How big can discovery frames get?
• Who will use them, and for what?
• Is fragmentation possible?

10
EAP Methods

• Flaws
• No mandatory to implement EAP method in IEEE
  802.11i
• Authentication server needed in simplest
  deployments
• Fix PSK mode
• Inability to use standard EAP key naming schemes
• Vulnerability to dictionary attack
• EAP method requirements defined late in the
  process
• Results
• Explosion in proprietary EAP methods lacking
  adequate review
• Flaws found in many proposals
• Interoperability problems widespread
• PSK may be crackable in some implementations
• Method rewrites required to meet the method
  requirements
• Deployments using unacceptable methods less
  secure than WEP!
• How to do better
• Define a mandatory to implement method
• Define EAP method requirements early on
• Leverage IETF standardization process
• References

11
State Machine Issues

• Flaws
• Association/Reassociation/Disassociation/
  Deauthenticate messages not protected.
• Cant base a security protocol on a state machine
  governed by insecure frames, so
• Functionality duplicated in the IEEE 802.11i
  authenticated key management (AKM) protocol
• Results
• Denial of service attacks at a distance
• Confusion between standards (IEEE 802.11F vs.
  802.11i)
• Excessive complexity
• How to do better
• Think through the basic state machine early on
• Keep it simple!

12
802.11-1999 State Machine
State 1Unauthenticated, Unassociated
Class 1 Frames
DeAuthentication Notification
Deauthentication notification
Successful Authentication
State 2Authenticated, Unassociated
Class 1 2 Frames
Successful Association or Reassociation
Disassociation Notification
State 3Authenticated, and Associated
Class 1, 2 3 Frames
13
How This Probably Should Have Worked
State 1Unauthenticated, Unassociated
Class 1 Frames
PMK Delete
PMK Install
PTK/PMK Delete
State 2Authenticated, Unassociated
Class 1 2 Frames
PTK Install
PTK Delete
State 3Authenticated, and Associated
Class 1, 2 3 Frames
14
IEEE 802.11i Authenticated Key Mgmt
Supplicant
Authenticator
Key (PMK) is Known Generate SNonce
Key (PMK) is Known Generate ANonce
Message 1 EAPOL-Key(ANonce, Unicast)
Derive PTK
Message 2 EAPOL-Key(SNonce, Unicast, MIC)
Derive PTK If needed, generate GTK
Message 3 EAPOL-Key(Install PTK, Unicast, MIC,
GTK)
Message 4 EAPOL-Key(Unicast, MIC)
Install PTK and GTK
Install PTK
15
AKM Issues

• Flaws
• Too many exchanges
• Handshake is 6-way when Association/Reassociation
  exchange included (for PMK negotiation)
• 4-way handshake initiated by authenticator, not
  supplicant
• GTK transport is uni-directional
• How to do better
• Remember that state needs to be synchronized on
  both sides
• Remember that keys may need to be deleted as well
  as installed
• Draw simple box and arrow diagrams before diving
  into details
• References
• EAP Key Management Framework

16
How STA-Initiated AKM Might Work
Supplicant
Authenticator
Key (PMK) is Known Generate SNonce
Key (PMK) is Known Generate ANonce
Message 1 EAPOL-Key(SNonce, Unicast)
Derive PTK, Generate GTK
Message 2 EAPOL-Key(ANonce, Unicast, MIC, GTK)
Derive PTK, Generate GTK
Message 3 EAPOL-Key(Install PTK GTK, Unicast,
MIC, GTK)
Message 4 EAPOL-Key(Unicast, MIC)
Install PTK and GTK
Install PTK and GTK
17
Key Handling Issues

• IEEE 802.11i added PMK caching and security
  association descriptions late in the process
• Flaws
• Key scoping not explicit
• With whom can the authenticator share the key?
• With what NICs can the supplicant use the key?
• What PMKs on what supplicants are valid for use
  with which authenticators?
• Is a seperate supplicant PMK cache required per
  SSID? What about the AP PMK cache?
• Key scoping not currently supported within RADIUS
• Authorized SSIDs, Called-Station-Ids,
  Calling-Station-Ids
• Key naming based on the key itself
• Potential for dictionary attack on the PMKID
• Result
• Supplicant can authenticate as GUEST, do a fast
  handoff to the CORPNET SSID
• How to do better
• Think through the key caching and scoping issues
  beforehand
• Utilize established key naming schemes
• References
• EAP Key Management Framework

18
Feedback?