IEEE 802.11i: A Retrospective - PowerPoint PPT Presentation

1 / 18
About This Presentation
Title:

IEEE 802.11i: A Retrospective

Description:

Denial of service vulnerabilities partially addressed ... No detailed discussion of DoS vulnerabilities ... Distinguish between DoS attacks. Attacks from afar ... – PowerPoint PPT presentation

Number of Views:67
Avg rating:3.0/5.0
Slides: 19
Provided by: Bernar138
Category:
Tags: 11i | ieee | dos | retrospective

less

Transcript and Presenter's Notes

Title: 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?
Write a Comment
User Comments (0)
About PowerShow.com