Capwap Mailing List: Response to LWAPP Security Review

[Pat Calhoun (pcalhoun]

The co-authors of the LWAPP draft believe that security is of the utmost importance for the working group, and therefore asked Charles to perform a review of the draft-ohara-capwap-lwapp-02.txt specification. I would like to personally thank Charles for his detailed analysis of the LWAPP protocol, as well as the associated review document. I believe that his review further strengthens the fact that the LWAPP protocol meets the security objectives the co-authors had laid out for ourselves.

 

Charles mentioned that the PSK mode is cryptographically secure. On the other hand, while the certificate based approach is practically secure, Charles had some recommendations to also make it cryptographically secure. I would like to respond to these recommended changes.

 

1. Add an additional round to perform explicit key validation.

LWAPP introduced an additional round in the join phase in the -02 draft, but it is currently only used for the pre-shared key approach. We will modify the certificate approach within the protocol to make use of this new round to perform explicit key validation.

2. Increase size of SID to 128 bits to prevent replay attacks.

The Session Identifier is actually used in two ways. First, it is used to uniquely identify a session during the key exchange. Second, the data tunneling component of LWAPP uses the session id in its headers. Unfortunately, increasing the session id size to 128 bits will unnecessarily increase the overhead associated with the tunneling header. Therefore, after careful consideration, we believe that the best approach is to in fact increase the session id size during the key exchange, but clearly state within the specification that only the least significant 32 bits are used in the LWAPP data tunnel header.

3. Require AC certificates to contain an extended usage authorizing them to provide AC services.

The authors have considered including a proposed X.509 certificate profile in the specification for some time, but opted to leave it out until a future version. However, Charles' comment makes it clear that including it within the LWAPP specification is required in order to address this concern. In the X.509 certificates we use today, we require that both the AP and the AC include their LWAPP mode of operation (e.g., AC, WTP) to order to bind the certificate to a role.

Charles also had the suggested change for encryption purposes:

4. Secure derivation of the initialization vector, at least by the AC, but preferably by both the AC and WTP

Today, the WTP implicitely choses the IV through the Session Identifier. We will make a change to allow the AC to select the most significant 64 bits of the IV during the join phase.

Chales also mentioned the following suggestions to mitigate future attacks:

5. Perform key derivation based on exchanged entropy, rather than having the AC push a key to the WTP

This is the mode of operation used for pre-shared key, and we will extend this mechanism to the certificate based approach.

Finally, Charles recommends adding the following text:

6. Normatively RECOMMEND that LWAPP not be used with 802.11 WEP

There is nothing about LWAPP that causes WEP to be more vulnerable, but Charles is recommending that a statement be included stating that WEP not be supported on LWAPP ACs/WTPs. This is a note for implementers with the understanding that there are many legacy devices in the field that only support WEP and cannot be upgraded. Therefore, it may not be practical for vendors to stop supporting WEP.

7. Add text stating that handoffs must be authenticated, for example by requiring a successful 802.11 rekey before moving a session from one WTP to another.

Again, this is an implementation issue, and the LWAPP document does not include sufficient text in the delete mobile on when this to be issued during a handoff. While the authors know how to implement this in a secure fashion, Charles is right that a third party may not consider the implications of sending the delete mobile prior to an authenticated handoff, and therefore some additional text is warranted.

 

Once more, thanks to Charles for the great review.

 

I have a question for the chairs. Given that we initiated this review, I would like to know if it would be possible to address these issues and repost an updated version of the draft for consideration. I believe that it is in the best interest of the Working Group, and the Internet Community, to be working off a protocol that has had a security review.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems