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

David Harrington <ietfdbh@comcast.net> Sat, 28 June 2014 03:22 UTC

Return-Path: <ietfdbh@comcast.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070E01A0283 for <secdir@ietfa.amsl.com>; Fri, 27 Jun 2014 20:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73tzizrS6RG6 for <secdir@ietfa.amsl.com>; Fri, 27 Jun 2014 20:22:41 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEC41A027D for <secdir@ietf.org>; Fri, 27 Jun 2014 20:22:41 -0700 (PDT)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta08.westchester.pa.mail.comcast.net with comcast id KfL71o0091c6gX858fNhuC; Sat, 28 Jun 2014 03:22:41 +0000
Received: from [50.94.114.15] ([50.94.114.15]) by omta23.westchester.pa.mail.comcast.net 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 <ietfdbh@comcast.net>
In-Reply-To: <21421.29586.427961.926637@fireball.kivinen.iki.fi>
Date: Fri, 27 Jun 2014 23:22:22 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <C7D3BE6A-8690-4A05-875A-0E0B85DEE839@comcast.net>
References: <21421.29586.427961.926637@fireball.kivinen.iki.fi>
To: Tero Kivinen <kivinen@iki.fi>
X-Mailer: Apple Mail (2.1878.2)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; 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==
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/gj_XEII2uu1UK9Ob31bUKLNprLw
Cc: draft-ietf-eman-energy-monitoring-mib.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [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: Sat, 28 Jun 2014 03:22:45 -0000

Hi,

comments inline.

dbh

On Jun 27, 2014, at 9:37 AM, Tero Kivinen <kivinen@iki.fi>; 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
> (http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security).

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. 
> -- 
> kivinen@iki.fi
> 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview