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

Hi,

I forgot to mention:

    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.

Fine with me to change the title to "Power and Energy Monitoring and 
Control MIB"
All instances of "Power and Energy Monitoring MIB" in the draft should 
be changed too.

Regards, Benoit
> 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<kivinen@iki.fi>  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.
>>> -- 
>>> kivinen@iki.fi
>>>
>>> _______________________________________________
>>> secdir mailing list
>>> secdir@ietf.org
>>> https://www.ietf.org/mailman/listinfo/secdir
>>> wiki:http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>> .
>>
>