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

Catherine Meadows <catherine.meadows@nrl.navy.mil> Mon, 01 December 2014 19:39 UTC

Return-Path: <catherine.meadows@nrl.navy.mil>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5D8081A8A44; Mon, 1 Dec 2014 11:39:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HiK5YkL3lnYt; Mon, 1 Dec 2014 11:38:57 -0800 (PST)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E4591A89F9; Mon, 1 Dec 2014 11:37:40 -0800 (PST)
Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil []) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id sB1JbcjZ021017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 1 Dec 2014 14:37:38 -0500
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3D80B6AA-ACDE-473E-87FD-5F783E6E955B"
Date: Mon, 1 Dec 2014 14:37:38 -0500
Message-Id: <F9015C12-9822-4B22-85CE-467F7BF29A32@nrl.navy.mil>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-opsawg-capwap-hybridmac.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-CCS-MailScanner: No viruses found.
X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/XijaeiL67PouNhVVYBu6dLtwnvM
Subject: [secdir] Secdir review of draft-ietf-opsawg-capwap-hybridmac-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Dec 2014 19:39:00 -0000

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.  


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: catherine.meadows@nrl.navy.mil