Issue Discussion: KeyRSC (43)

1. Issue Discussion: KeyRSC (43) November 2006 dstanley@arubanetworks.com

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

3. Issue 43 KeyRSC Issue Description

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

5. Extend the IEEE 802.11 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 802.11 Binding to deliver the GTK KeyRSC from the WTP to the AC 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 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 Alternative Solutions