Subject: Re: [secdir] SECDIR review of draft-ietf-eman-energy-aware-mib-15

From: Benoit Claise <[email-masked]>
Date: Tue, 01 Jul 2014 13:26:03 +0200

Hi Stephen,

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
Our mistake for using a previous boilerplate.

Regards, Benoit
> Hi,
>
> there is a security boilerplate that we are following.
>
> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security
>
> If you think this is not appropriate anymore, we need to have a
> discussion to update the boilerplate instead of debating specific MIB
> modules.  Note that this topic comes up periodically - usually without
> much changes to the boilerplate at the end. Lets see the result this
> time. ;-)
>
> /js
>
> On Tue, Jun 24, 2014 at 11:48:02AM -0400, Stephen Kent wrote:
>> 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.
>> _______________________________________________
>> secdir mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/secdir
>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>

---

From: Benoit Claise <[email-masked]>
Date: Tue, 08 Jul 2014 09:15:43 +0200

Stephen,

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

Regards, Benoit
> 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.
>
> 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 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 
> 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 
> 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?
>
> 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.