Doc.: IEEE 802.11-04/1062r0 Submission September 2004 F. Bersani, France Telecom R&DSlide 1 Dominos,...
-
Upload
basil-wiggins -
Category
Documents
-
view
213 -
download
0
Transcript of Doc.: IEEE 802.11-04/1062r0 Submission September 2004 F. Bersani, France Telecom R&DSlide 1 Dominos,...
September 2004
F. Bersani, France Telecom R&D
Slide 1
doc.: IEEE 802.11-04/1062r0
Submission
Dominos, bonds and watches: discussion of some security
requirements for TGrFlorent Bersani, France Telecom R&D
September 2004
F. Bersani, France Telecom R&D
Slide 2
doc.: IEEE 802.11-04/1062r0
Submission
Goal of this presentation• Loren Adams once said: "What is understood need
not be discussed"• This presentation is about discussing some tentative
security requirements listed in document IEEE 802.11-04/10048r0:– Sharing of the PMK
– Binding of the PMK
– Timeliness of messages
• ... and make sure 09/13 discussion is captured
September 2004
F. Bersani, France Telecom R&D
Slide 3
doc.: IEEE 802.11-04/1062r0
Submission
Sharing of the PMK
• Sharing of the PMK is explicitly prohibited by IEEE 802.11i:– Page 38, clause 8.1.4 item 5 "An IEEE 802.1X
AS never exposes the common symmetric key to any party except the AP with which the STA is currently communicating. (...)"
September 2004
F. Bersani, France Telecom R&D
Slide 4
doc.: IEEE 802.11-04/1062r0
Submission
Sharing of the PMK
• Sharing of the PMK is explicitly prohibited by IEEE 802.11i:– Page 38, clause 8.1.4 item 5 ctd. "It implies that
the AS itself is never compromised. It also implies that the IEEE 802.1X AS is embedded in the AP, or the AP is physically secure and the AS and the AP lie entirely within the same administrative domain."
September 2004
F. Bersani, France Telecom R&D
Slide 5
doc.: IEEE 802.11-04/1062r0
Submission
Sharing of the PMK
• Yet practice does not seem to comply with this requirement (e.g., RADIUS proxying), should TG r?
• Possible rationale for this requirement:– The domino effect– Sound cryptographic practice
September 2004
F. Bersani, France Telecom R&D
Slide 6
doc.: IEEE 802.11-04/1062r0
Submission
Sharing of the PMK
• This is reflected in document IEEE 802.11-04/10048r0, requirements:– #2: "In particular, the pairs <STA, AP1> and
<STA, AP2> must have cryptographically independent PMKs, or all the 802.11i security claims are voided. This rules out sharing PMKs among different APs."
– #7: "A PMK shall never be shared between APs"
September 2004
F. Bersani, France Telecom R&D
Slide 7
doc.: IEEE 802.11-04/1062r0
Submission
Sharing of the PMK
• The domino effect– Housley, R., "Key Management in AAA",
Presentation to the AAA WG at IETF 56, http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html
– "Compromise of a single authenticator cannot compromise any other part of the system, including session keys and long-term secrets."
September 2004
F. Bersani, France Telecom R&D
Slide 8
doc.: IEEE 802.11-04/1062r0
Submission
Sharing of the PMK
• The domino effect– Compromise of long term secrets would be
really painful... but PMKs are not long term (except in PSK mode)
– Domino protection is useful when the network has the possibility to inform STA of the compromised AP• Could also very well do it for PMKID... if it is not
"too broadly shared"
September 2004
F. Bersani, France Telecom R&D
Slide 9
doc.: IEEE 802.11-04/1062r0
Submission
Sharing of the PMK
• Sound cryptographic practice– Reusing a nonce can void security properties (e.g.,
Counter mode)• However, if nonce is random then collision probability
can be bounded
– A key has limited lifetime• Sharing it, speeds up burning out. For 128 bit block
length, assuming 54 Mbit/s, 0.4*10**14 s with 1 AP
– PMK is generally for a short period of time and used in a somewhat conservative scheme
September 2004
F. Bersani, France Telecom R&D
Slide 10
doc.: IEEE 802.11-04/1062r0
Submission
Sharing of the PMK
• Anyway what is an AP?
• Not particularly advocating sharing the PMKs... just debating!
September 2004
F. Bersani, France Telecom R&D
Slide 11
doc.: IEEE 802.11-04/1062r0
Submission
Binding the PMK
• This "requirement" appeared during discussion of IEEE 802.11-04/10048r0
• Perhaps alluded to in requirement #9 "The only visible identifier seems to be BSSID."
• The idea would be that:– A PMK should only be used by a pair <AP,STA>– This restriction should be "incorporated" in the
PMK
September 2004
F. Bersani, France Telecom R&D
Slide 12
doc.: IEEE 802.11-04/1062r0
Submission
Binding the PMK• Is the PTK bound to something?
– It incorporates nonces and MAC addresses...– Yet this does not per se preclude sharing of the
PTK!
• How can we prevent two parties that have agreed to do so to abuse a key usage???
• What does "binding the keys" mean?– EAP channel binding?
September 2004
F. Bersani, France Telecom R&D
Slide 13
doc.: IEEE 802.11-04/1062r0
Submission
Timeliness of messages• This is reflected in document IEEE 802.11-
04/10048r0, requirements – #11 "An AP shall test the liveness of the mobile STA
at reassociation when the mobile STA does a secure fast transition to it. This is required to synchronize replay counters."
– #12. "A mobile STA shall test the liveness of the AP at reassociation when it does a secure fast transition to a new AP. This is required to synchronize replay counters"
September 2004
F. Bersani, France Telecom R&D
Slide 14
doc.: IEEE 802.11-04/1062r0
Submission
Timeliness of messages• The attack scenario:
CCMP protected frame, PN=23:
"Sell stocks, now!"
Attacker delays the frame (and possibly
subsequent traffic)
• This is not a replay: client only sees the delayed frame once
CCMP protected frame, PN=23:
"Sell stocks, now!"
September 2004
F. Bersani, France Telecom R&D
Slide 15
doc.: IEEE 802.11-04/1062r0
Submission
Timeliness of messages• 802.11i does not include such a feature,
why:– Hard to do? (timestamps, ...)– Not necessary? (client won't stay associated
with big delays)
• Should TGr?– What if pre-auth is allowed to go up to deriving
a PTK: there can be some time between derivation and usage
– Avoid DoS and black-holes
September 2004
F. Bersani, France Telecom R&D
Slide 16
doc.: IEEE 802.11-04/1062r0
Submission
Timeliness of messages• Solution alluded to to provided timeliness:
periodically make a protected resynch of replay counters– Kind of a key confirmation– Tradeoff between the frequency of this resynch
and the "timeliness" protection
September 2004
F. Bersani, France Telecom R&D
Slide 17
doc.: IEEE 802.11-04/1062r0
Submission
Conclusion• TG r PAR: "Security must not be decreased as a
result of the enhancement."
• To what extent has TG r to comply with TG i?– Is there an objective measure of security diminution?
– TG r can break some of TG i assumptions, yet prove that it remains secure...
• H2 make Apples to apples comparison between securtiy of the proposals?