Re: [MIB-DOCTORS] Change the boilerplate
"Bert Wijnen (IETF)" <bertietf@bwijnen.net> Thu, 10 July 2014 08:00 UTC
Return-Path: <bertietf@bwijnen.net>
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EB21A0397 for <mib-doctors@ietfa.amsl.com>; Thu, 10 Jul 2014 01:00:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNStQ3dGMwwG for <mib-doctors@ietfa.amsl.com>; Thu, 10 Jul 2014 01:00:57 -0700 (PDT)
Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F871A0371 for <mib-doctors@ietf.org>; Thu, 10 Jul 2014 01:00:57 -0700 (PDT)
Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from <bertietf@bwijnen.net>) id 1X59He-00015D-VT; Thu, 10 Jul 2014 10:00:53 +0200
Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest9.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from <bertietf@bwijnen.net>) id 1X59He-0005QI-Rl; Thu, 10 Jul 2014 10:00:50 +0200
Message-ID: <53BE4833.3060506@bwijnen.net>
Date: Thu, 10 Jul 2014 10:00:51 +0200
From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>, "MIB Doctors (E-mail)" <mib-doctors@ietf.org>
References: <CFE17DDA.458C3%alissa@cooperw.in> <53BC5081.6090809@cisco.com> <53BD6690.2040102@cisco.com> <53BE3D7E.2090302@bwijnen.net> <53BE4018.8030402@cisco.com>
In-Reply-To: <53BE4018.8030402@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd42e7306b09fc88f6d3c14c7cfa5d77177
Archived-At: http://mailarchive.ietf.org/arch/msg/mib-doctors/o87r4ejSAukrgB4ahzhUVeE-abg
Cc: Adrian Farrel <adrian@olddog.co.uk>, 'Alissa Cooper' <alissa@cooperw.in>, sec-ads@tools.ietf.org
Subject: Re: [MIB-DOCTORS] Change the boilerplate
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list <mib-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mib-doctors/>
List-Post: <mailto:mib-doctors@ietf.org>
List-Help: <mailto:mib-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jul 2014 08:01:00 -0000
I can see that for IoT related MIB modules there might be specific privacy concerns that you might want to describe in a special section. Not sure this should become a standard section in all MIB related documents though. My 2 cents. Bert On 10/07/14 09:26, Benoit Claise wrote: > >> it is always interesting to see that when we get new ADs that we must rediscuss this whole topic. > Wait, there is more, two DISCUSSes from Kathleen regarding the boilerplate (copied the Security ADs): > http://datatracker.ietf.org/doc/draft-ietf-eman-battery-mib/ballot/#kathleen-moriarty > http://datatracker.ietf.org/doc/draft-ietf-eman-energy-aware-mib/ballot/#kathleen-moriarty > > I would like to hear first from you guys before providing my opinion. > > Regards, Benoit >> >> But yes, there are/were implementations/deployments where one uses dedicated (secure) networks >> for the network management systems, and so that would work under a SHOULD. >> >> I do not recall if that was/is the only reason why we agreed on a SHOULD instead of MUST. >> >> Bert >> >> On 09/07/14 17:58, Benoit Claise wrote: >>> MIB doctors, >>> >>> Let me focus the discussion a little bit. >>> 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]. >>> >>> >>> Alissa's feedback is: >>> >>> It is a little disconcerting that use of SNMPv3 is provided as a SHOULD-level requirement without discussion of deployment >>> scenarios and regardless of the sensitivity of the data being made available by any new MIB. For example, the tradeoffs between >>> security and utility might be reasonable if (1) I’m using an older SNMP version on my closed home network to monitor my own >>> energy use, but not if (2) my ISP is using it to monitor the same thing. The text quoted above basically endorses unauthorized >>> energy monitoring if the provider does not support SNMPv3, whereas it seems like what we would want to be saying is that in >>> cases like (2) SNMPv3 is required. >>> >>> Can one of the old timers (who was part of the discussion) explain the SHOULD rational? Personally, I can see two use cases in favor >>> off the SHOULD: an older SNMP version in a closed network, or a private data communication network dedicated to network management >>> with special protection out of SNMP (like encrypted tunnel) >>> >>> Should we now modify this sentence to say? >>> >>> MUST provide the security features described by the >>> SNMPv3 framework (see [RFC3410]) >>> >>> Regards, Benoit >>> >>>> MIB doctors, >>>> >>>> It seems that the "Security Guidelines for IETF MIB modules" receives comment for each MIB module submitted to the IESG. >>>> Is it time to modify it, or are we redoing the same discussions over and over? >>>> >>>> Regards, Benoit >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: Re: Alissa Cooper's Discuss on draft-ietf-eman-energy-monitoring-mib-12: (with DISCUSS and COMMENT) >>>> Date: Tue, 8 Jul 2014 13:02:50 -0700 >>>> From: Alissa Cooper <alissa@cooperw.in> >>>> To: Benoit Claise <bclaise@cisco.com>, The IESG <iesg@ietf.org> >>>> CC: <draft-ietf-eman-energy-monitoring-mib@tools.ietf.org>, <eman-chairs@tools.ietf.org> >>>> >>>> >>>> >>>> Hi Benoit, >>>> >>>> On 7/8/14, 1:44 AM, "Benoit Claise" <bclaise@cisco.com <mailto:bclaise@cisco.com>> wrote: >>>> >>>> Hi Alissa, >>>> >>>> Thanks for your review. >>>>> Alissa Cooper has entered the following ballot position for >>>>> draft-ietf-eman-energy-monitoring-mib-12: Discuss >>>>> >>>>> When responding, please keep the subject line intact and reply to all >>>>> email addresses included in the To and CC lines. (Feel free to cut this >>>>> introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer tohttp://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here: >>>>> http://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib/ >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> Section 11 is missing a discussion of the privacy considerations of >>>>> energy and power monitoring. I would suggest something along the lines of >>>>> the following: >>>>> >>>>> "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." >>>> >>>> Regarding your first sentence, I propose the following text, which would be in line with Security Guidelines for IETF MIB >>>> modules at http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security >>>> >>>> Some of the readable objects in this MIB module (i.e., objects with a >>>> MAX-ACCESS other than not-accessible) may be considered sensitive or >>>> vulnerable in some network environments. It is thus important to >>>> control even GET and/or NOTIFY access to these objects and possibly >>>> to even encrypt the values of these objects when sending them over >>>> the network via SNMP. These are the tables and objects and their >>>> sensitivity/vulnerability: >>>> >>>> Access to the content of the eoPowerStateTable, eoEnergyTable, and >>>> eoACPwrAttributesTable MIB tables can reveal sensitive >>>> information about individuals' activities and habits >>>> >>>> Sounds good to me. >>>> >>>> >>>> Since this document is essentially a MIB module, your last sentence is covered by >>>> >>>> implementations >>>> claiming compliance to the SNMPv3 standard MUST include full >>>> support for authentication and privacy via the User-based >>>> Security Model (USM) [RFC3414 <http://tools.ietf.org/html/rfc3414>] with the AES cipher algorithm >>>> [RFC3826 <http://tools.ietf.org/html/rfc3826>]. >>>> >>>> RFC 6988 notes the need for privacy protections for stored data, which the above text does not speak to, so I still think a >>>> reference to RFC 6988 would add value here. >>>> >>>> It is a little disconcerting that use of SNMPv3 is provided as a SHOULD-level requirement without discussion of deployment >>>> scenarios and regardless of the sensitivity of the data being made available by any new MIB. For example, the tradeoffs between >>>> security and utility might be reasonable if (1) I’m using an older SNMP version on my closed home network to monitor my own energy >>>> use, but not if (2) my ISP is using it to monitor the same thing. The text quoted above basically endorses unauthorized energy >>>> monitoring if the provider does not support SNMPv3, whereas it seems like what we would want to be saying is that in cases like >>>> (2) SNMPv3 is required. >>>> >>>> I understand that this is basically boilerplate language for MIB docs, so I’m not sure what can be done, but it seems unfortunate. >>>> >>>> Alissa >>>> >>>> >>>> >>>>> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> Section 12.1: >>>>> "New Assignments (and potential deprecation) to Power State Sets >>>>> shall be administered by IANA and the guidelines and procedures >>>>> are specified in [EMAN-FMWK], and will, as a consequence, the >>>>> IANAPowerStateSet Textual Convention should be updated." >>>>> >>>>> Not sure what this sentence means. >>>> Good catch. >>>> NEW: >>>> >>>> "New Assignments (and potential deprecation) to Power State Sets >>>> shall be administered by IANA and the guidelines and procedures >>>> are specified in [EMAN-FMWK], and will, as a consequence, update the >>>> IANAPowerStateSet Textual Convention." >>>> >>>> >>>> Regards, Benoit (as a document author) >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> MIB-DOCTORS mailing list >>>> MIB-DOCTORS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>> >>> >>> >>> _______________________________________________ >>> MIB-DOCTORS mailing list >>> MIB-DOCTORS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mib-doctors >>> >> . >> > >
- [MIB-DOCTORS] Fwd: Re: Alissa Cooper's Discuss on… Benoit Claise
- Re: [MIB-DOCTORS] Fwd: Re: Alissa Cooper's Discus… Thomas D. Nadeau
- [MIB-DOCTORS] Change the boilerplate (was: Fwd: R… Benoit Claise
- Re: [MIB-DOCTORS] Change the boilerplate Bert Wijnen (IETF)
- Re: [MIB-DOCTORS] Change the boilerplate Benoit Claise
- Re: [MIB-DOCTORS] Change the boilerplate Bert Wijnen (IETF)
- Re: [MIB-DOCTORS] Change the boilerplate Romascanu, Dan (Dan)
- Re: [MIB-DOCTORS] Change the boilerplate Stephen Farrell
- Re: [MIB-DOCTORS] Change the boilerplate Thomas D. Nadeau
- Re: [MIB-DOCTORS] Change the boilerplate - Kathle… Benoit Claise
- Re: [MIB-DOCTORS] Change the boilerplate - Kathle… Stephen Farrell
- Re: [MIB-DOCTORS] Change the boilerplate - Kathle… Romascanu, Dan (Dan)
- Re: [MIB-DOCTORS] Change the boilerplate - Alissa… Benoit Claise
- Re: [MIB-DOCTORS] Change the boilerplate - Kathle… Kathleen Moriarty
- Re: [MIB-DOCTORS] Change the boilerplate - Kathle… Juergen Schoenwaelder
- Re: [MIB-DOCTORS] Change the boilerplate - Alissa… Juergen Schoenwaelder
- Re: [MIB-DOCTORS] Change the boilerplate - Alissa… Romascanu, Dan (Dan)
- Re: [MIB-DOCTORS] Change the boilerplate - Alissa… Kathleen Moriarty
- Re: [MIB-DOCTORS] Change the boilerplate - Alissa… Alissa Cooper
- Re: [MIB-DOCTORS] Change the boilerplate David Harrington
- Re: [MIB-DOCTORS] Change the boilerplate - Kathle… ietfdbh
- Re: [MIB-DOCTORS] Change the boilerplate - Alissa… ietfdbh
- Re: [MIB-DOCTORS] Change the boilerplate - Alissa… ietfdbh
- Re: [MIB-DOCTORS] Change the boilerplate - Kathle… Kathleen Moriarty