Subject: [secdir] Secdir review of draft-ietf-opsawg-capwap-hybridmac-06

From: Catherine Meadows <[email-masked]>
Date: Mon, 1 Dec 2014 14:37:38 -0500

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

I believe that this document is ready, with minor issues in the Security Considerations Section. 

This ID concerns the correction of an ambiguity in the CAPWAP protocol.  That protocol supports two Medium Access Control (MAC) modes with respect to
two entities: a Wireless Transmission Point (WTP) and an Access Controller (AC).  In one of the modes, split mode, encryption functionality can be located at either
the WTP or the AC, but no clear way is given of having the AC inform the WTP of where the encryption functionality should be located.  This ID presents a means by which
the WTP informs the AC of the various MAC profiles it supports, and then the AC determines the appropriate profile and configures the WTP with the profile while configuring
the WLAN.

The Security Considerations Section says that this document does not introduce any new security risks compared to RFC5416, and that the security considerations
described in RFC5416 apply here as well.  I believe that a document that addresses the placement of encryption functionality should say something more, in particular
*why* it introduces no new security risks.  In the case of negotiation, the main security risk is that an attacker could interfere with the negotiation so that a less secure
alternative is chosen even when a more secure one is available.  In the security considerations section of RFC5416 it is noted that there is a possibility of a
replay attack if encryption resides at the WTP.  The risk is slight, and the only way of closing the security gap is expensive, so the authors of RFC5416 decide to let
the risk stand.  However, this presents a conceivable attack in which an attacker could cause an AC to believe that a WTP only supports   encryption functionality at the WTP,
and the AC would choose the less secure mode.  Although the risk this introduces is also slight, I believe that this should be mentioned. Also, would I be correct in assuming
that a WTP that supports encryption at the WTP but not at the AC is unlikely? If that is so, it might be possible to close the security gap by having the ATP reject advertisements (request
a retransmit?) that only support encryption at the WTP, and if so you should mention that too.  

Nits:

The word “clearly” is repeated in line 7 of the abstract.  

Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: [email-masked]