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

Benoit Claise <> Tue, 08 July 2014 07:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 096461B2A62; Tue, 8 Jul 2014 00:20:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K3wqJXcQV7Gp; Tue, 8 Jul 2014 00:20:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 167331B2A5C; Tue, 8 Jul 2014 00:20:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=13635; q=dns/txt; s=iport; t=1404804047; x=1406013647; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=iPOp14hh5KmN8uL3V7fCYb2E5IiRV2bHsDpHTy0HARw=; b=Gt9iy00f/K+3dFJHyu1Sh909Zw0ybhXUrUAg5r21BzKpAHEAP4JutJwt gcREYewZCseQ55mWpdgOB8NVe1bEXYvEb9WocteW14tqsNPLXyQnD9B96 WntoqgT+ViluJUXkpPHYCvVQN2kI6yJkciFGrLM4SbN1Dpm2nRDcnBRRc U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.01,624,1400025600"; d="scan'208,217";a="102366113"
Received: from (HELO ([]) by with ESMTP; 08 Jul 2014 07:20:45 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id s687Kird030827; Tue, 8 Jul 2014 07:20:44 GMT
Message-ID: <>
Date: Tue, 08 Jul 2014 09:20:43 +0200
From: Benoit Claise <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: David Harrington <>, Tero Kivinen <>
References: <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------020409020505040702000102"
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: Tue, 08 Jul 2014 07:20:50 -0000

Dear all,

draft-ietf-eman-energy-monitoring-mib-12 has been posted with the 
correct boilerplate.

Regards, Bneoit

> Hi David, Tero,
> Thanks for your review.
> We will post a new draft version with this boilerplate at 
> We will also correct "theeoPowerAdminState"
> Finally, wrt your comment:
>     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.
> This is one of those legacy draft published with word :-)
> Regards, Benoit
>> Hi,
>> comments inline.
>> dbh
>> 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:
>> .