Re: [secdir] Secdir review of draft-ietf-opsawg-vmm-mib-02

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 25 May 2015 15:02 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF77B1A9053; Mon, 25 May 2015 08:02:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level:
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 sjS5o2TgtfzG; Mon, 25 May 2015 08:02:54 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789F71A904F; Mon, 25 May 2015 08:02:53 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 295F31015; Mon, 25 May 2015 17:02:52 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id AwTJot_xAVgu; Mon, 25 May 2015 17:02:49 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 25 May 2015 17:02:50 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87AB22002B; Mon, 25 May 2015 17:02:50 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dG6XPd2tvo5v; Mon, 25 May 2015 17:02:48 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E894720013; Mon, 25 May 2015 17:02:47 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id D69D933564BF; Mon, 25 May 2015 17:02:46 +0200 (CEST)
Date: Mon, 25 May 2015 17:02:46 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Christian Huitema <huitema@huitema.net>
Message-ID: <20150525150245.GA62786@elstar.local>
Mail-Followup-To: Christian Huitema <huitema@huitema.net>, 'The IESG' <iesg@ietf.org>, secdir@ietf.org, draft-ietf-opsawg-vmm-mib.all@tools.ietf.org
References: <00bb01d08df0$8d92f3f0$a8b8dbd0$@huitema.net> <20150523061335.GA58453@elstar.local> <019f01d09682$b04a7950$10df6bf0$@huitema.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <019f01d09682$b04a7950$10df6bf0$@huitema.net>
User-Agent: Mutt/1.4.2.3i
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/nXazPr2kRiOqqdDOevPE_wu6VAU>
Cc: draft-ietf-opsawg-vmm-mib.all@tools.ietf.org, 'The IESG' <iesg@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-opsawg-vmm-mib-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 May 2015 15:02:59 -0000

On Sun, May 24, 2015 at 05:35:22PM -0700, Christian Huitema wrote:
> Yes, your security section does mention the need to control GET as well.
> 
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> > Sent: Friday, May 22, 2015 11:14 PM
> > To: Christian Huitema
> > Cc: 'The IESG'; secdir@ietf.org;
> draft-ietf-opsawg-vmm-mib.all@tools.ietf.org
> > Subject: Re: Secdir review of draft-ietf-opsawg-vmm-mib-02
> > 
> > Christian,
> > 
> > thanks for the review. I am not sure if anything needs changes. The
> > draft largely follows the security considerations template for MIB
> > modules. And there is explicit text about GET access:
> > 
> >    [...]  Moreover, the objects in the vmTable,
> >    vmCpuTable, vmCpuAffinityTable, vmStorageTable and vmNetworkTable
> >    list information about the virtual machines and their virtual
> >    resource allocation.  Some may wish not to disclose to others how
> >    many and what virtual machines they are operating.
> > 
> >    It is thus important to control even GET access to these objects and
> >    possibly to even encrypt the values of these object when sending them
> >    over the network via SNMP.  Not all versions of SNMP provide features
> >    for such a secure environment.
> > 
> > Is this text not already covering your concerns? Below the quoted
> > text, there is the general boilerplate recommendation to avoid SNMPv1
> > and to use SNMPv3 instead.
> 
> The "GET" paragraph feels a bit generic. I would personally be a bit
> stronger. Something like, "It is NOT RECOMMENDED" to provide access to these
> variables without using the strong security features of SNMPv3. Of course,
> this is a generic problem with SNMP, and I understand your desire to use the
> generic text.

It seems on every second I-D that contains a MIB module we receive
suggestions to change the boilerplate. The boilerplate was settled
between security ADs and ops ADs and as a mere user of it I prefer to
stick to whatever these folks have worked out.

>  But is there a good reason to not recommend v3?

It is there (page 50):

   It is recommended that the implementers consider the security
   features as provided by the SNMPv3 framework.  Specifically, the use
   of the User-based Security Model [RFC3414] and the View-based Access
   Control Model [RFC3415] is recommended.
 
> I would also mention the specific problem of software running in a virtual
> machine and accessing the hypervisor's variables. This is an attack vector
> that is somewhat specific to this MIB. It cannot be mitigated by network
> firewalls.

This MIB module is typically implemented on the hypervisor not inside
a virtual machine. I guess I do not follow what your concern is.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>