1. Florent Bersani, France Telecom R&D
September 2002
doc.: IEEE /xxxr0
September 2004
Dominos, bonds and watches: discussion of some security requirements for TGr
Florent Bersani, France Telecom R&D
F. Bersani, France Telecom R&D
Eleanor Hepworth, Siemens

2. Goal of this presentation
September 2004
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 /1048r0:
Sharing of the PMK
Binding of the PMK
Timeliness of messages
... and make sure 09/13 discussion is captured
F. Bersani, France Telecom R&D

3. September 2004
Sharing of the PMK
Sharing of the PMK is explicitly prohibited by IEEE i:
Page 38, clause 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. (...)"
NB: Clause is informative
F. Bersani, France Telecom R&D

4. September 2004
Sharing of the PMK
Sharing of the PMK is explicitly prohibited by IEEE i:
Page 38, clause 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."
NB: Clause is informative
F. Bersani, France Telecom R&D

5. September 2004
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
F. Bersani, France Telecom R&D

6. September 2004
Sharing of the PMK
This is reflected in document IEEE /1048r0, requirements:
#2: "In particular, the pairs <STA, AP1> and <STA, AP2> must have cryptographically independent PMKs, or all the i security claims are voided. This rules out sharing PMKs among different APs."
#7: "A PMK shall never be shared between APs"
F. Bersani, France Telecom R&D

7. Sharing of the PMK The domino effect
September 2004
Sharing of the PMK
The domino effect
Housley, R., "Key Management in AAA", Presentation to the AAA WG at IETF 56,
"Compromise of a single authenticator cannot compromise any other part of the system, including session keys and long-term secrets."
F. Bersani, France Telecom R&D

8. Sharing of the PMK The domino effect
September 2004
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"
F. Bersani, France Telecom R&D

9. Sharing of the PMK Sound cryptographic practice
September 2004
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
F. Bersani, France Telecom R&D

10. Sharing of the PMK Anyway what is an AP?
September 2004
Sharing of the PMK
Anyway what is an AP?
Not particularly advocating sharing the PMKs... just debating!
F. Bersani, France Telecom R&D

11. September 2004
Binding the PMK
This "requirement" appeared during discussion of IEEE /1048r0
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
F. Bersani, France Telecom R&D

12. Binding the PMK Is the PTK bound to something?
September 2004
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?
F. Bersani, France Telecom R&D

13. Timeliness of messages
September 2004
Timeliness of messages
This is reflected in document IEEE /1048r0, 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"
F. Bersani, France Telecom R&D

14. Timeliness of messages
September 2004
Timeliness of messages
The attack scenario:
CCMP protected frame, PN=23:
"Sell stocks, now!"
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
F. Bersani, France Telecom R&D

15. Timeliness of messages
September 2004
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
F. Bersani, France Telecom R&D

16. Timeliness of messages
September 2004
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
F. Bersani, France Telecom R&D

17. Another security aspect to take into account
September 2004
Another security aspect to take into account
Although IEEE & i leave the door quite open to many DoS attacks...
We probably want to make sure that 11r does not make things even worse for that regard, e.g,
Allowing a STA to exhaust resources of many APs thanks to a badly-designed pre-auth scheme
Allowing a STA to make other STAs' traffic flow in a dead hole
F. Bersani, France Telecom R&D

18. September 2004
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?
F. Bersani, France Telecom R&D