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

David Harrington <> Sat, 28 June 2014 03:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 070E01A0283 for <>; Fri, 27 Jun 2014 20:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 73tzizrS6RG6 for <>; Fri, 27 Jun 2014 20:22:41 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:80]) by (Postfix) with ESMTP id 9CEC41A027D for <>; Fri, 27 Jun 2014 20:22:41 -0700 (PDT)
Received: from ([]) by with comcast id KfL71o0091c6gX858fNhuC; Sat, 28 Jun 2014 03:22:41 +0000
Received: from [] ([]) by with comcast id KfNN1o00N0Kzn4J3jfNR2D; Sat, 28 Jun 2014 03:22:38 +0000
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: David Harrington <>
In-Reply-To: <>
Date: Fri, 27 Jun 2014 23:22:22 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Tero Kivinen <>
X-Mailer: Apple Mail (2.1878.2)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1403925761; bh=wZ6hef+WQVctpFrq/P+06SDxw0oxBUYVxJWtRNRc5Go=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=SVfvjgu++LDhzuw+kWRQRmjyltVgYtgrAkNutKUFVGEZd2cmurQcmBOAqi0R+qva5 +X+FzuWpuz+mIqo4AmEq9ZUPZra1XZMT4JTaUkKVvKh/cVxhZMF6F2kicnev2kBMsf 5tktkTHPIsCktKhEZ0/CeHGl7NYdcrTyQTsC/FuDwMzbblXflSwz1qDIicUloqHPAY BhwHrmaPPQEGCIvjRd1P8c+wdyG5gcl/3zfHzijDbpythx0wcPVTfEuMYJW0GUmhG8 z6oACN/8eWd2tdCYQdTx2Tjy7gHwcl/GDZLw2CrCmWFzUxIoxRhKnBqTkVn+P9tjKA 8DyFaL/z0WjCw==
Subject: Re: [secdir] Secdir review of draft-ietf-eman-energy-monitoring-mib-10.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 28 Jun 2014 03:22:45 -0000


comments inline.


On Jun 27, 2014, at 9:37 AM, Tero Kivinen <> wrote:

> 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).

These are the old guidelines. 

> 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.

Yeah, but it’s the best that could be negotiated at that point in time.

> The guidelines text instead makes SHOULD for providing
> security.
> Why is this text changed from the mib-security framework
> (

The document was probably based on an older mib document.
It MIGHT have been based on the templates on the tools page before I got them updated.

The document should be updated to the new boilerplate.

> 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
> environments.

without changing the boilerplate, of course …

> 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. 
> Nits:
> 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
> editor. 
> -- 
> _______________________________________________
> secdir mailing list
> wiki: