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

[Benoit Claise <[e-mail]>]

Hi David, Tero,

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

We will also correct "theeoPowerAdminState"

Finally, wrt your comment:

    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.

This is one of those legacy draft published with word :-)

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