Presentation is loading. Please wait.

Presentation is loading. Please wait.

TGr D2.0 Security Issues Date: Authors: May 2006 Month Year

Similar presentations


Presentation on theme: "TGr D2.0 Security Issues Date: Authors: May 2006 Month Year"— Presentation transcript:

1 TGr D2.0 Security Issues Date: 2006-05-15 Authors: May 2006 Month Year
doc.: IEEE yy/xxxxr0 May 2006 TGr D2.0 Security Issues Date: Authors: Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at Housley, Sood, Walker John Doe, Some Company

2 Month Year doc.: IEEE yy/xxxxr0 May 2006 Goals This submission summarizes several security issues identified in P802.11r D2.0, and proposes solutions to these problems Disclaimer: This submission does not claim to have identified all security issues raised by P802.11r D2.0 (or even all major security issues). It only discusses the security issues that we have identified thus far. Housley, Sood, Walker John Doe, Some Company

3 Agenda Keying Issues Base Mechanism Issues Reservation Issue
Month Year doc.: IEEE yy/xxxxr0 May 2006 Agenda Keying Issues PMK-R1 derivation Simultaneous PMK-R0 instantiations Base Mechanism Issues Session Identity Flooding attacks against message 3 Flooding attacks against message 4 Reservation Issue Flooding attacks Housley, Sood, Walker John Doe, Some Company

4 Keying Issue 1: PMK-R1 derivation
Month Year doc.: IEEE yy/xxxxr0 May 2006 Keying Issue 1: PMK-R1 derivation One of the original r design goals was to allow a mobile STA to distinguish Correct PMK sharing among thin APs managed by the same controller, and Sharing a PMK among compromised fat APs The PMK-R1 is defined as PMK-R1 = kdf(PMK-R0, “R1 Key Derivation”, PMKR0Name || R1KH-ID || 0x00 || SPA) Housley, Sood, Walker John Doe, Some Company

5 Keying Issue 1: PMK-R1 derivation
Month Year doc.: IEEE yy/xxxxr0 May 2006 Keying Issue 1: PMK-R1 derivation Attack 1: Compromise a fat AP At a second fat AP (not necessarily in the same MD), provision the R1HK-ID and the PMK-R1s from the compromised AP STAs will use the same PMK-R1 to derive PTKs, violating the design goal Attack 2 If controller passes the PMK-R1 to one of its thin APs, the same attack works if one of the controllers is compromised instead of a thin AP and the second fat AP is replaced by a thin AP. Attack 3 If there is more than one controller, the same attack works if one controller is compromised and the second fat AP is replaced by another controller Housley, Sood, Walker John Doe, Some Company

6 Keying Issue 1: PMK-R1 derivation
Month Year doc.: IEEE yy/xxxxr0 May 2006 Keying Issue 1: PMK-R1 derivation Recommendation: All three attacks can be eliminated by Associating a single AP with each R1KH Setting R1KH-ID = the BSSID of the AP associated with the R1KH The PMK-R1 becomes PMK-R1 = kdf(PMK-R0, “R1 Key Derivation”, PMKR0Name || BSSID || 0x00 || SPA) Observation: The performance goal of using a single PMK-R1 across multiple APs is at odds with the TGr security goals Comment 1: If TGr maintains a many-to-one relationship between APs and R1KHs, then the multi-level key hierarchy adds little security value Comment 2: The r design assumes that the R0KH is highly resistant to compromise; this assumption needs to be explicitly documented Housley, Sood, Walker John Doe, Some Company

7 Keying Issue 2: Simultaneous PMK-R0 Instantiations
Month Year doc.: IEEE yy/xxxxr0 May 2006 Keying Issue 2: Simultaneous PMK-R0 Instantiations A STA may perform FT Initial Association with multiple APs within the same mobility domain Each FT Initial Association creates a different PMK-R0, perhaps at different R0KHs P802.11r D2.0 defines no mechanism to invalidate a prior PMK-R0 at a different R0KH (nor its subordinate PMK-R1 keys) Attack on simultaneous PMK-R0 instantiations: Compromise or steal the PMK-R0 of any mobile client Induce the client to run FT Initial Association with a new R0KH Use the compromised PMK-R0 with any AP associated with the original R0KH (which is all APs within the same MD) Housley, Sood, Walker John Doe, Some Company

8 Keying Issue 2: Simultaneous PMK-R0 Instantiations
Month Year doc.: IEEE yy/xxxxr0 May 2006 Keying Issue 2: Simultaneous PMK-R0 Instantiations Recommendation: The attack can be eliminated by invalidating, at all R0KHs in the mobility domain, any PMK-R0 associated with the STA MAC address when a new PMK-R0 is instantiated This mechanism may be hard, and possibly outside TGr scope Hence r can only specify its assumptions about a solution Alternative Recommendation: (within scope of r) Make the Mobility Domain Controller the R0KH for everyone Comment 1: This problem mirrors from the AP’s perspective what was Keying Issue 1 from the STA’s Housley, Sood, Walker John Doe, Some Company

9 Base Mechanism Issue 1: Session Identity
Month Year doc.: IEEE yy/xxxxr0 May 2006 Base Mechanism Issue 1: Session Identity Message 1 sends SNonce from the STA to the AP Message 2 sends ANonce (but not SNonce) from the AP to the STA Unlike the i 4-Way Handshake, the STA has no assurance that Message 2 is fresh (or even part of this association) The 4-Way Handshake proves to the AP that Message 2 is fresh by using a MIC calculated over ANonce Without fresh messages, difficult to have security This also enables a flooding attack against the STA (see Base Mechanism Issue 3) Recommendation: Either insert a MIC into message 2, or include both SNonce and ANonce in message 2, or both Housley, Sood, Walker John Doe, Some Company

10 Base Mechanism Issue 2: Flooding attacks against message 3
Month Year doc.: IEEE yy/xxxxr0 May 2006 Base Mechanism Issue 2: Flooding attacks against message 3 Attack: Attacker generates a large volume of SNonce values and sends them to the AP, each in a separate Message 1 For each SNonce, the AP must maintain a pair <SNonce, ANonce> (memory) or the derived PTK (CPU and less memory) for the STA’s MAC address to prevent a trivial denial-of-service flooding attack The AP must generate the same ANonce value for each flooded SNonce value to avoid a trivial flooding attack against Message 4 (See Base Mechanism Issue 3) For each SNonce, the STA sends Message 3 with a random string in place of a legitimate MIC The Message 3 MIC verification will fail on each message, but the AP must compute the PTK with the proper SNonce to verify (and reject) the MIC Housley, Sood, Walker John Doe, Some Company

11 Base Mechanism Issue 2: Flooding attacks against message 3
Month Year doc.: IEEE yy/xxxxr0 May 2006 Base Mechanism Issue 2: Flooding attacks against message 3 The flooding attack on Message 3 succeeds because P802.11r D2.0 does not require the STA to commit to a particular SNonce value for each session Message 3 sends ANonce instead of SNonce, to signal the AP which PTK to use to verify the MIC Sending ANonce is a performance optimization at the expense of security Recommendation: Specify that the STA must commit to an SNonce value for each instance of the base mechanism Insert SNonce into message 3 Either replacing ANonce in message 3 or sending both SNonce and ANonce in message 3 (preferred) Housley, Sood, Walker John Doe, Some Company

12 Base Mechanism Issue 3: Flooding attacks against message 4
Month Year doc.: IEEE yy/xxxxr0 May 2006 Base Mechanism Issue 3: Flooding attacks against message 4 Attack: The attacker generates a large volume of ANonce values and sends them to the STA, each in a separate Message 2 For each ANonce, the STA must maintain a pair <SNonce, ANonce> (memory) or the derived PTK (CPU and less memory) for the AP’s MAC address to prevent a trivial denial-of-service flooding attack with Message 2 For each ANonce, the AP sends Message 4 with a random MIC The Message 4 MIC verification will fail on each message, but the STA must compute the PTK with the proper ANonce to verify (and reject) the MIC Housley, Sood, Walker John Doe, Some Company

13 Base Mechanism Issue 3: Flooding attacks against message 4
Month Year doc.: IEEE yy/xxxxr0 May 2006 Base Mechanism Issue 3: Flooding attacks against message 4 The flooding attack on Message 4 succeeds because P802.11r D2.0 does not require the AP to commit to a particular ANonce value for each instance of the FT base mechanism Message 4 sends SNonce instead of ANonce, to signal the STA which PTK to use to verify the MIC Sending SNonce is a performance optimization at the expense of security Recommendation: Specify that the AP must commit to an ANonce value for each instance of the base mechanism Insert ANonce into message 4 Either replacing SNonce in message 4 or sending both SNonce and ANonce in message 4 (preferred) Housley, Sood, Walker John Doe, Some Company

14 Reservation Issue: Flooding attacks
Month Year doc.: IEEE yy/xxxxr0 May 2006 Reservation Issue: Flooding attacks The P802.11r D2.0 design has no mechanism to limit the number of reservations made by any client Attack: For each AP in the mobility domain use over-the-DS to send that AP a reservation request An AP could implement a metering scheme to prevent over-the-DS abuse of reservation Alternate attack Spread the colluding clients across the mobility domain For each mobility domain AP within range, use over-the-air to send that AP a reservation request Housley, Sood, Walker John Doe, Some Company

15 Reservation Issue: Flooding attacks
Month Year doc.: IEEE yy/xxxxr0 May 2006 Reservation Issue: Flooding attacks With either approach a small number of clients can use this to allocate all of the bandwidth in the mobility domain Recommendation: impose an enforceable metering scheme that applies to both over-the-air and over-the DS, or else remove reservation Housley, Sood, Walker John Doe, Some Company

16 Month Year doc.: IEEE yy/xxxxr0 May 2006 Summary We have identified a number of non-trivial security flaws exist in P802.11r D2.0 This is not surprising or unusual for a document at this early stage of maturity This submission recommends simple mechanisms to correct most of the security flaws found thus far The r draft should undergo a much more thorough security review, and the issues raised by any such review addressed, before it advances to Sponsor Ballot TGr needs to take the time to get the security right Housley, Sood, Walker John Doe, Some Company

17 Discussion? May 2006 Month Year doc.: IEEE 802.11-yy/xxxxr0
Housley, Sood, Walker John Doe, Some Company


Download ppt "TGr D2.0 Security Issues Date: Authors: May 2006 Month Year"

Similar presentations


Ads by Google