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

[David Harrington <[e-mail]>]

Hi,

comments inline.

dbh

On Jun 27, 2014, at 9:37 AM, Tero Kivinen <[e-mail]> wrote:

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

These are the old guidelines. 

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

Yeah, but it’s the best that could be negotiated at that point in time.

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

The document was probably based on an older mib document.
It MIGHT have been based on the templates on the tools page before I got them updated.

The document should be updated to the new boilerplate.

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

without changing the boilerplate, of course …

> 
> 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]
> 
> _______________________________________________
> secdir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview