Re: [MIB-DOCTORS] Change the boilerplate - Alissa's DISCUSS

[Alissa Cooper <[e-mail]>]

Perhaps rather than re-discussing the boilerplate, we could discuss what
the purpose of the boilerplate is.

If the purpose of the boilerplate is to provide text that authors can look
at and say, “yes, in the case of this document, the boilerplate fully
covers the security considerations of the MIB being specified,” then I
think it’s a great thing to have. If the purpose of the boilerplate is to
keep any additional security consideration not covered in the boilerplate
from being addressed in a MIB document, then it seems overly constricting.

Security considerations change over time. I’m assuming that home/device
energy monitoring wasn’t really top of mind when SNMP was developed or
when the boilerplate was originally written. So it’s not surprising that
new security issues are arising that aren’t addressed within the
boilerplate. If the boilerplate were just a suggestion of text and not a
limitation on what can be documented, we could accommodate the changing
times fairly easily.

In my original DISCUSS, all I suggested was text that could be provided in
addition to the boilerplate:

"In certain situations, energy and power monitoring can reveal sensitive
information about individuals' activities and habits. Implementors of this
specification should use appropriate privacy protections as discussed in
Section 9 of RFC 6988 and monitoring of individuals and homes should only
occur
with proper authorization.”

I have not had time to look at Stephen’s comments but I agree with him and
Bert that adding a special section or extra text to discuss privacy
concerns in the IoT-related documents is the right way to go.

Alissa


On 7/10/14, 8:11 AM, "Juergen Schoenwaelder"
<[e-mail]> wrote:

>On Thu, Jul 10, 2014 at 04:13:08PM +0200, Benoit Claise wrote:
>> Dear all,
>> 
>> The email below refers to Alissa's DISCUSS
>> See 
>> 
>>http://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib/bal
>>lot/#alissa-cooper
>> 
>> Alissa refers to this sentence in the boilerplate at
>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security
>> 
>>         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].
>> 
>> From the discussion (Dan andBert's feedback, on top of mine) , it seems
>> that there are valid reasons to keep a SHOULD here in the generic
>> boilerplate.
>> 
>> So what next?
>> - Should we justify the reasons in the boiler plate
>> - Should we  give some freedom in the boilerplate?
>> 
>>         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].
>> 
>>         <if there are use cases where a MUST is required, described
>> them here>
>> 
>>   Now, I hope it will not be abused by Security ADs, requesting a MUST
>> for every single MIB module.
>> - Something else?
>> - Stop writing MIB modules :-)
>> 
>
>Do nothing, re-discuss this every other year. ;-)
>
>/js
>
>-- 
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
>Fax:   [phone]         <http://www.jacobs-university.de/>