Re: [secdir] Secdir review of draft-ietf-eman-energy-monitoring-mib-10.txt
Benoit Claise <bclaise@cisco.com> Tue, 08 July 2014 07:20 UTC
Return-Path: <bclaise@cisco.com>
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 096461B2A62; Tue, 8 Jul 2014 00:20:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3wqJXcQV7Gp; Tue, 8 Jul 2014 00:20:48 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 167331B2A5C; Tue, 8 Jul 2014 00:20:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: AqUEAHCbu1OtJssW/2dsb2JhbABZg2C/TAGGcFMBgSt1hAMBAQEDAQEBAWsKAQULCw4KCRYPCQMCAQIBFTAGAQwBBQIBAYg2CA3JFxeJZYRvTgeEQwEEmnaBSIVHjH2DRTsv
X-IronPort-AV: E=Sophos;i="5.01,624,1400025600"; d="scan'208,217";a="102366113"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 08 Jul 2014 07:20:45 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s687Kird030827; Tue, 8 Jul 2014 07:20:44 GMT
Message-ID: <53BB9BCB.8090907@cisco.com>
Date: Tue, 08 Jul 2014 09:20:43 +0200
From: Benoit Claise <bclaise@cisco.com>
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 <ietfdbh@comcast.net>, Tero Kivinen <kivinen@iki.fi>
References: <21421.29586.427961.926637@fireball.kivinen.iki.fi> <C7D3BE6A-8690-4A05-875A-0E0B85DEE839@comcast.net> <53B29817.3090905@cisco.com>
In-Reply-To: <53B29817.3090905@cisco.com>
Content-Type: multipart/alternative; boundary="------------020409020505040702000102"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/1UBeFNPM-sNf-2JhrGXiFf6YFzk
Cc: iesg@ietf.org, draft-ietf-eman-energy-monitoring-mib.all@tools.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: 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 > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security > > 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<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 >> . >> >
- [secdir] Secdir review of draft-ietf-eman-energy-… Tero Kivinen
- Re: [secdir] Secdir review of draft-ietf-eman-ene… David Harrington
- Re: [secdir] Secdir review of draft-ietf-eman-ene… Benoit Claise
- Re: [secdir] Secdir review of draft-ietf-eman-ene… Benoit Claise
- Re: [secdir] Secdir review of draft-ietf-eman-ene… Benoit Claise