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

From: Stephen Kent <[email-masked]>
Date: Tue, 24 Jun 2014 11:48:02 -0400

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.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Jun 2014 22:47:19 +0200

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

> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 26 Jun 2014 12:44:00 -0400

Juergen,

I read the boilerplate you cited.

The comment re IPsec is misleading, for the reasons I noted in my review.
This is the first MIB I-D I've reviewed. I would have pointed out the 
problems
with that text earlier had I reviewed a MIB earlier :-).

With the publication of RFC 7258 as a BCP its seems appropriate to revisit
the boilerplate when discussing confidentiality and use of encryption. 
Hence
my suggestion that use of encryption be RECOMMENDED.

Since the subject of this MIB is energy management, I think that my 
comments about
the potential adverse impacts of security lapses for these MIBs are 
relevant. This
is outside the generic context for which the boilerplate was developed.

Finally, the boilerplate does not seem to use the same language as the 
text at the end
of the SC, e.g., I don't see the word "consider" in the boilerplate. The 
mix of advice dealing
with implementation vs. deployment still strikes me as confusing, as 
written. I think the
boilerplate text is better in this respect, and should be used as a 
starting point for
the last part of the SC in this I-D (tailored as needed).

Steve