[secdir] SECDIR review of draft-ietf-eman-framework-07

Yoav Nir <ynir@checkpoint.com> Thu, 20 February 2014 07:22 UTC

Return-Path: <ynir@checkpoint.com>
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 0678E1A064F; Wed, 19 Feb 2014 23:22:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.449
X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id d6BTGFftoK0J; Wed, 19 Feb 2014 23:22:12 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6F28E1A0422; Wed, 19 Feb 2014 23:22:12 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s1K7M7Tw032224; Thu, 20 Feb 2014 09:22:07 +0200
Received: from IL-EX10.ad.checkpoint.com ([]) by DAG-EX10.ad.checkpoint.com ([]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 09:22:07 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: "<secdir@ietf.org>" <secdir@ietf.org>, "<iesg@ietf.org> IESG" <iesg@ietf.org>, "draft-ietf-eman-framework.all@tools.ietf.org" <draft-ietf-eman-framework.all@tools.ietf.org>
Thread-Topic: SECDIR review of draft-ietf-eman-framework-07
Thread-Index: AQHPLgx1Ya8fUKe8SUm7crencxxdfA==
Date: Thu, 20 Feb 2014 07:22:06 +0000
Message-ID: <523EEFE5-315C-4A49-B802-1F7C31B7ADD9@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <591A1EFD1817CB4D9729B625002D5394@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Pr9FtjphKsdcvt4D-kwW1xR2cNs
Subject: [secdir] SECDIR review of draft-ietf-eman-framework-07
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: Thu, 20 Feb 2014 07:22:15 -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.

Although I am reviewing this for SECDIR, I have to begin with some editorial remarks. I don't know what tool was used, but it's producing a very ill-formatted draft. It's true that the RFC editor staff will get it right, but it is apparent that this is a combination of several sources. See for example section 2 for a jarring mixture of line lengths.  Or the broken-in-half artwork of Figure 1 at the bottom of page 14. When you do that, someone (that's the RFC editor) has to put your diagrams back together, an error-prone process that should be done by the authors.

The middle of section 1 has a paragraph whose entire text is "Energy Management Documents Overview". Was this supposed to be the title to a subsection?

The document also contains some parts that are supposed to be removed before publication, for example the URL to the issue tracker. Please add a label like "RFC EDITOR NOTE: REMOVE THE FOLLOWING PARAGRAPH" before this. They know to look for it, and we don't end up with things we didn't want in the draft.

Speaking of issues, I followed that URL, and found that it is showing three open issues. Are these resolved?

I confess to being totally ignorant of the subject matter, but reading through this I noticed something that surprised me. In section 3.1 there is this paragraph:
        A simple device such as a light bulb can be switched on or off 
        only by switching its power supply.  More complex devices may 
        have the ability to switch off themselves or to bring 
        themselves to states in which they consume very little power.
Is the "may" here appropriate? Don't these complex devices *require* that they switch themselves off rather than have their power switched off?

Finally, the security considerations section. The most important recommendation there is to use SNMPv3, because it includes authentication and privacy, unlike earlier versions. I agree with the recommendation, but it should be noted that authentication was part of SNMPv1 as well, although different mechanisms (not based on community strings) were only added in SNMPv3. "Privacy" is a loaded term with multiple meanings. In SNMP privacy simply means confidentiality, and it's preferable to use that term rather than "privacy" which today is no longer used interchangeably with confidentiality.

The section does an OK job of enumerating the risks, but IMO downplays them. For example, "Unauthorized changes to the Energy Management Domain or business context of an Energy Object may result in misreporting or interruption of power."  There's no "may" about it. If an attacker can modify the energy management domain, then they can at least shut down the network.