[secdir] Secdir review of draft-ietf-eman-energy-monitoring-mib-10.txt

Tero Kivinen <kivinen@iki.fi> Fri, 27 June 2014 13:37 UTC

Return-Path: <kivinen@iki.fi>
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 2164A1B2BC1; Fri, 27 Jun 2014 06:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.772
X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 60f4ivIMGf7w; Fri, 27 Jun 2014 06:37:26 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969291B2BBC; Fri, 27 Jun 2014 06:37:25 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost []) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s5RDbN7T029985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Jun 2014 16:37:23 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s5RDbMOo005135; Fri, 27 Jun 2014 16:37:22 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <21421.29586.427961.926637@fireball.kivinen.iki.fi>
Date: Fri, 27 Jun 2014 16:37:22 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-eman-energy-monitoring-mib.all@tools.ietf.org
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 19 min
X-Total-Time: 23 min
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/gWVRQeFr1uu6h3QNlN13fblVdrg
Subject: [secdir] Secdir review of draft-ietf-eman-energy-monitoring-mib-10.txt
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: Fri, 27 Jun 2014 13:37:32 -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

This document describes the MIB for energy monitoring. It has mostly
read only information about the current energy use etc, but it also
have one important writable attribute eoPowerAdminState which can be
used to change the power state of the device (shut it down?). The MIB
also have second part which can be used to create notifications and
intervals for enery usage.

Both of these are pointed out in the security consideations section
and the security considerations section mostly follows the MIB
security guidelines text, but differs in one paragraph. The text in
draft says:

       It is RECOMMENDED that implementers consider the security
       features as provided by the SNMPv3 framework (see [RFC3410],
       section 8), including full support for the SNMPv3 cryptographic
       mechanisms (for authentication and privacy).

Where the guidelines text says:

      Implementations SHOULD provide the security features described
      by the SNMPv3 framework (see [RFC3410]), and implementations
      claiming compliance to the SNMPv3 standard MUST include full
      support for authentication and privacy via the User-based
      Security Model (USM) [RFC3414] with the AES cipher algorithm
      [RFC3826]. Implementations MAY also provide support for the
      Transport Security Model (TSM) [RFC5591] in combination with a
      secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353].

Asking implementors to consider security features is something that
cannot be verified, i.e. there is no way I can see whether the
implementor x actually even considered the security features or not,
thus making RECOMMENDATION to consider security feature is just
stupid. The guidelines text instead makes SHOULD for providing

Why is this text changed from the mib-security framework

Also I think the security considerations section should mention that
almost all of the MIB items do have privacy issues, as for example
reading the power usage of the home TV/PC/game console/washing machine
will give indication whether person is at home, and what he might be
doing. Thus the first paragraph saying "Some objects may be considered
sensitive", I would say most of the objects are sensitive in most

Actually it seems to bit dangerous to have mostly read-only
information in MIB where the only read-write item is the very security
sensitive object which can be used to turn the devices off. Especially
when the MIB name is Power and Energy MONITORING MIB. Casual operator
might just check the MIB name and then notice there is lots of
read-only information like "eoPowerNamePlate" or "eoPowerAccuracy",
etc and just assume this is only for monitoring the power usage, and
not notice that it also allows turning device on and off via one
read-write value hidden among the read-only values.

I would be more happy if that one read-write value would be moved to
separate MIB, but I do not know if there is better place for it. If it
is not moved, then it would be better to change the title of the draft
o say "Power and Energy Monitoring and Control MIB" or something
similar which indicates more clearly that this MIB can be used to
control devices. 


In section 11:

       - Unauthorized changes to the eoPowerOperState (via
         theeoPowerAdminState ) MAY disrupt the power settings of the

s/theeoPowerAdminState/the eoPowerAdminState/.

The formatting of the draft was bit wierd in places (extra ^L in the
middle of page etc), but I assume those will be fixed by the RFC