Return-Path: 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 7E4DA1B2A7B for ; Tue, 8 Jul 2014 00:15:51 -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 v6djONq8Ow7e for ; Tue, 8 Jul 2014 00:15:49 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120B91B2A5C for ; Tue, 8 Jul 2014 00:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32918; q=dns/txt; s=iport; t=1404803748; x=1406013348; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=W/8+Zoi7ehUxlyxG64dx1KlyJ/VMjqHjP5Q4B+quaSY=; b=fmqgjVe+bzMiQPM5/UBeT71tsHfpl+fsZ0H5ZVwdG0QQEi6dwdfX2wbT vlmEqk1HaLvzdbQoyWULimogjb/Ue9Y7d5xHwgtHWupJwQm+xPtbbwufR Z8Y4LAathljmJv6kVYYZ/Oc3ZNIvAmnLTxAWeGTITvKnLG9yrTL+QVYJk o=; X-IronPort-AV: E=Sophos;i="5.01,624,1400025600"; d="scan'208,217";a="102341140" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 08 Jul 2014 07:15:46 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s687Fi5L005265; Tue, 8 Jul 2014 07:15:45 GMT Message-ID: <53BB9A9F.1090601@cisco.com> Date: Tue, 08 Jul 2014 09:15: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: Stephen Kent , secdir , jparello@cisco.com, moulchan@cisco.com, n.brownlee@auckland.ac.nz, tnadeau@lucidvision.com, joel jaeggli References: <53A99DB2.5050707@bbn.com> In-Reply-To: <53A99DB2.5050707@bbn.com> Content-Type: multipart/alternative; boundary="------------000607030408020401050601" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/tXpVOfSXexlyVIujND8L7jcnUnw Subject: Re: [secdir] SECDIR review of draft-ietf-eman-energy-aware-mib-15 X-BeenThere: secdir@ietf.org 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:15:51 -0000 This is a multi-part message in MIME format. --------------000607030408020401050601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stephen, draft-ietf-eman-energy-aware-mib-v16 has been posted with the correct Security boilerplate. Regards, Benoit > > I 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. Since I am not a MIB expert, > my comments are strictly related to the security-relevant aspects of > this document. > > This document, as its name implies, defines a MIB for energy > management devices. Given increasing concern over security in the > so-called "cyber-physical" realm, a MIB for such devices clearly > merits scrutiny. Also, to the extent that such devices (e.g., meters) > might be associated with residences, there are personal privacy issues > that ought to be addressed, in the PERPASS era. > > The document is clearly written; my compliments to the authors in that > regard. The one odd thing I noted was that Sections 11.1 and 11.2 > appear between Sections 6 and 7! I think this was a cut and paste > error that is easily remedied. > > The Security Considerations section (7) is about one-half page in > length. I have several concerns with the text here. > > First, the text says "It is thus important to control even GET and/or > NOTIFY access to these objects and possibly to even encrypt the values > of these objects when sending them over the network via SNMP." This > seems to be an understatement. I'd like to see the text here RECOMMEND > use of encryption to provide confidentiality. This would be supportive > of personal privacy, in residential contexts, and physical security in > residential and enterprise settings. I can imagine a movie in which > burglars use a lack of encryption to gain critical information about > building infrastructure from a an energy MIB J. > > The text later says "There are a number of management objects defined > in these MIB modules with a MAX-ACCESS clause of read-write and/or > read-create.Such objects MAY be considered sensitive or vulnerable in > some network environments.The support for SET operations in a > non-secure environment without proper protection can have a negative > effect on network operations. Again, this strikes me as a significant > understatement, i.e., the scope of the "negative effect" could be much > broader that just a network. (Power outlets are cited as examples of > objects, so anything plugged into an outlet could be effected, right?) > There should be more emphasis on the need for access control. > > The text later says "SNMP versions prior to SNMPv3 did not include > adequate security. Even if the network itself is secure (for example, > by using IPsec), there is still no secure control over who on the > secure network is allowed to access and GET/SET > (read/change/create/delete) the objects in these MIB modules." This is > a misleading. IPsec natively provides access control. It would be > accurate to say that the access controls offered by IPsec would only > limit who could access the MIB. What the authors seem to suggest here > is finer-grained access control, so that one can manage GET/SET > privileges for the set of individuals who are authorized to connect to > the MIB via the SMTP port, right? > > The text discussing use of SNMPv3 security is a bit confusing. > > It RECOMMENDS that implementers "consider" SMNPv3 security features, > but then says deployment of SNMP versions prior to v3 is NOT > RECOMMENDED. The first paragraph discussing this topic deals with > thinking about support (vs. use) of SNMPv3, while the second paragraph > makes a much stronger statement about deployment. It would be more > consistent to mandate support (MUST or SHOULD) for SNMPv3 in entities > that incorporate this MIB. Separately the document can RECOMMEND > enabling SNMPv3 security features in deployments, for the reasons cited. --------------000607030408020401050601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Stephen,

draft-ietf-eman-energy-aware-mib-v16 has been posted with the correct Security boilerplate.

Regards, Benoit

I 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. Since I am not a MIB expert, my comments are strictly related to the security-relevant aspects of this document.

 

This document, as its name implies, defines a MIB for energy management devices. Given increasing concern over security in the so-called “cyber-physical” realm, a MIB for such devices clearly merits scrutiny. Also, to the extent that such devices (e.g., meters) might be associated with residences, there are personal privacy issues that ought to be addressed, in the PERPASS era.

 

The document is clearly written; my compliments to the authors in that regard. The one odd thing I noted was that Sections 11.1 and 11.2 appear between Sections 6 and 7! I think this was a cut and paste error that is easily remedied.

 

The Security Considerations section (7) is about one-half page in length. I have several concerns with the text here.

 

First, the text says “It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP.” This seems to be an understatement. I’d like to see the text here RECOMMEND use of encryption to provide confidentiality. This would be supportive of personal privacy, in residential contexts, and physical security in residential and enterprise settings. I can imagine a movie in which burglars use a lack of encryption to gain critical information about building infrastructure from a an energy MIB J.

 

The text later says “There are a number of management objects defined in these MIB modules with a MAX-ACCESS clause of read-write and/or read-create.  Such objects MAY be considered sensitive or vulnerable in some network environments.  The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Again, this strikes me as a significant understatement, i.e., the scope of the “negative effect” could be much broader that just a network. (Power outlets are cited as examples of objects, so anything plugged into an outlet could be effected, right?)  There should be more emphasis on the need for access control.

 

The text later says “SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example, by using IPsec), there is still no secure control over who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in these MIB modules.” This is a misleading. IPsec natively provides access control. It would be accurate to say that the access controls offered by IPsec would only limit who could access the MIB. What the authors seem to suggest here is finer-grained access control, so that one can manage GET/SET privileges for the set of individuals who are authorized to connect to the MIB via the SMTP port, right?

 

The text discussing use of SNMPv3 security is a bit confusing.

It RECOMMENDS that implementers “consider” SMNPv3 security features, but then says deployment of SNMP versions prior to v3 is NOT RECOMMENDED. The first paragraph discussing this topic deals with thinking about support (vs. use) of SNMPv3, while the second paragraph makes a much stronger statement about deployment. It would be more consistent to mandate support (MUST or SHOULD) for SNMPv3 in entities that incorporate this MIB. Separately the document can RECOMMEND enabling SNMPv3 security features in deployments, for the reasons cited.

--------------000607030408020401050601--