Download Issue 43 Key RSC Discussion

November 2006
Issue Discussion: KeyRSC (43)
November 2006
[email protected]
November 2006
Key RSC (Issue 43)
1. The Issue
•
See the extensive list discussion, including Scott
and Charles’ security analysis
2. Alternative Resolutions
November 2006
Issue 43 KeyRSC Issue Description
WTP – 802.11
Encryption at WTP*
AC
WTP Performing IEEE 802.11 Encryption, maintains Current GTK KeyRSC value,
Have at least one Station active
Station
802.11 Authentication Request and Response, Association Request and Response
GTK KeyRSC =
Value from AC
GTK KeyRSC =
Value from WTP
IEEE 802.1X, EAP Exchange, 4-Way Handshake, M3 Includes Key RSC
GTK KeyRSC =
Value from WTP
*No Issue when IEEE 82.11 Encryption is at the AC
Also, NOT an AC-WTP Interoperability Issue; affects STA behavior
GTK KeyRSC =
Value from AC
Issue 43 – IEEE 802.11i Considerations
November 2006
•
•
•
•
In the current CAPWAP protocol, the 4-way handshake occurs between the AC and
the STA, and once this is complete, the AC pushes the 802.11 cryptographic key
material (the PTK) to the WTP. In cases where a GTK (the group transient key,
which is used to cryptographically protect broadcast/multicast traffic) is already
active for the ESSID the STA is associating to, the GTK is identified in message 3
of the 4-way handshake, along with the current receive sequence counter (KeyRSC)
for messages protected under that key. Since the WTP maintains the active
KeyRSC, the AC currently has no way to know precisely what the correct value is
at the point at which message 3 is constructed.
To work around this, LWAPP designers chose to have the AC simply set this value
to 0.
This decision does not affect the WTP, who maintains this counter; it only affects
the STA. Hence, there is no interoperability implication to this behavior. The STA,
upon receiving the first valid broadcast/multicast message from the WTP, will
update its RSC to the correct value, and will be synchronized with the WTP's value
from then on
List discussion – Scott and Charles’ security analysis problem description
November 2006
1.
Extend the IEEE 802.11 Binding to deliver the KCK to the WTP
–
–
2.
–
–
Propose adding a message element to 802.11 config response which would allow the WTP to return
the sequence number to the AC for use in GTK1.
Allows the AC to deliver a KeyRSC value that is closer to the actual value in use
Adds complexity to the protocol, possible timing delays; STA and WTP values still may not match
Document the issue in the IEEE 802.11 binding document security considerations section,
and do not extend the protocol and give no implementation advice
–
–
4.
Enables the WTP to create M3 of the 4-Way Handshake and deliver the correct value to the station
Adds complexity to the protocol, possible timing delays
Extend the IEEE 802.11 Binding to deliver the GTK KeyRSC from the WTP to the AC
–
3.
Alternative Solutions
No additional protocol complexity
“Length of the “window of vulnerability” is very small in most networks; acknowledge risk vs
complexity trade-off
Document the issue in the IEEE 802.11 binding document security considerations section,
do not extend the protocol, and add text to indicate that the “AC should set the KeyRSC
value to zero or other value”
–
–
–
No additional protocol complexity
“Length of the “window of vulnerability” is very small in most networks; acknowledge risk vs
complexity trade-off
Provide implementation guidance