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

[Stephen Kent <[e-mail]>]

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.