1. Issue Discussion: KeyRSC (43)
November 2006

2. Key RSC (Issue 43) The Issue Alternative Resolutions
See the extensive list discussion, including Scott and Charles’ security analysis
Alternative Resolutions

3. Issue 43 KeyRSC Issue Description

4. Issue 43 – IEEE 802.11i Considerations
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 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

5. Alternative Solutions
Extend the IEEE Binding to deliver the KCK to the WTP
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 Binding to deliver the GTK KeyRSC from the WTP to the AC
Propose adding a message element to 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 binding document security considerations section, and do not extend the protocol and give no implementation advice
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 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”
Provide implementation guidance