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

[Kathleen Moriarty <[e-mail]>]

On Thu, Jul 10, 2014 at 11:32 AM, Romascanu, Dan (Dan) <[e-mail]>
wrote:

> The way I always understood the boilerplate is that it provided a minimal
> mandatory text (and thus a minimal set of advice) for the Security
> Considerations sections of the MIB documents. Authors can always add
> security related content according to the specific of the work, and this is
> what authors have done many times.
>
> OK, I think the problem we ran into this time is that three drafts have
additional considerations that are not covered in the template.  In my
discuss, I suggested an optional section to be included and was trying some
other security considerations to tie it into Alissa's text for IoT, for
both privacy and security.

I appreciate the addition of text in the template discussed in another
thread.

Thanks,
Kathleen



> Regards,
>
> Dan
>
>
> > -----Original Message-----
> > From: Alissa Cooper [mailto:[e-mail]]
> > Sent: Thursday, July 10, 2014 6:28 PM
> > To: Juergen Schoenwaelder; Benoit Claise
> > Cc: Romascanu, Dan (Dan); Bert Wijnen (IETF); MIB Doctors (E-mail);
> Adrian
> > Farrel; [e-mail]
> > Subject: Re: [MIB-DOCTORS] Change the boilerplate - Alissa's DISCUSS
> >
> > 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/>
> >
>
>


-- 

Best regards,
Kathleen