[secdir] Secdir review of draft-ietf-eman-energy-monitoring-mib-10.txt

[Tero Kivinen <[e-mail]>]

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).

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. 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).

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.

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. 
-- 
[e-mail]