Re: [MIB-DOCTORS] Fix of Security Guidelines for IETF MIB Modules

Randy Presuhn <randy_presuhn@alumni.stanford.edu> Sat, 29 September 2018 17:56 UTC

Return-Path: <randy_presuhn@alumni.stanford.edu>
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068D8130DCB for <mib-doctors@ietfa.amsl.com>; Sat, 29 Sep 2018 10:56:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 hljba7rEEeBz for <mib-doctors@ietfa.amsl.com>; Sat, 29 Sep 2018 10:56:36 -0700 (PDT)
Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7F81286D9 for <mib-doctors@ietf.org>; Sat, 29 Sep 2018 10:56:36 -0700 (PDT)
Received: by mail-pg1-f181.google.com with SMTP id g12-v6so988958pgs.1 for <mib-doctors@ietf.org>; Sat, 29 Sep 2018 10:56:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sSVzcM2TSRs/9ejrXluAoZScdecL+QdrMdH59uXcD2A=; b=VCiNtOc3tnkhc5TL0nYsjfhrDCTfWElK0+Y6Yv8g7SsKv/TQe89BxIR2tHJyiUU6fV HesRZemifaXjqmE2SyYExwSy85ILZYNRB0oJXOp3IxnMVG0G+nZ8xf8qbJCBuebXimoG JG+XkYulsP+MX+Sd9n0lrb+T0UH7ziqL/4yvXVfzg1ffgNfQFh1QJlz/qPf8P74ScktY /wnnTcKeMPKwcW8q4kx/f0xDhGbbsrf1i4PHsFYZQCzOhfped1yTgKP+MZlAY7lAzWBf MIz2l25j4Ow14b4h8+9OmYJT0Ejj57JZ6IWPoaoc/Eh8/mruGYPn6Nmnv3i4f4rz4nsb kC8A==
X-Gm-Message-State: ABuFfoinRcXyaZpgsmBIBZZ2DkCv5oFgp8Mtq8zQhcFEvpLr+EvIkjjT cQiZnQxf+WMRJlVNO9ssHlnUnDXtcRg=
X-Google-Smtp-Source: ACcGV63wcmQlKoM0zkFjG9NxwGYW4WkOdgfDKD33cv5V+AEEkaR49jCSeEcSKIrnvRIgA/HDyXd7Rg==
X-Received: by 2002:a17:902:820a:: with SMTP id x10-v6mr4117348pln.261.1538243795456; Sat, 29 Sep 2018 10:56:35 -0700 (PDT)
Received: from [192.168.1.100] (c-69-181-241-121.hsd1.ca.comcast.net. [69.181.241.121]) by smtp.gmail.com with ESMTPSA id e24-v6sm11244877pff.128.2018.09.29.10.56.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Sep 2018 10:56:35 -0700 (PDT)
To: mib-doctors@ietf.org, warren@kumari.net, ibagdona@gmail.com, Glenn Mansfield Keeni <glenn@cysols.com>
References: <7f59ba0b-1358-1015-cd85-4c470ad73d9a@cysols.com>
From: Randy Presuhn <randy_presuhn@alumni.stanford.edu>
Message-ID: <f8bce0d0-cd96-7bd1-c785-e459860d863d@alumni.stanford.edu>
Date: Sat, 29 Sep 2018 10:56:30 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <7f59ba0b-1358-1015-cd85-4c470ad73d9a@cysols.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mib-doctors/9dJk8RjJBJwcfLD6JeA1iyjEguo>
Subject: Re: [MIB-DOCTORS] Fix of Security Guidelines for IETF MIB Modules
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 29 Sep 2018 17:56:38 -0000

Hi -

On 9/28/2018 11:52 PM, Glenn Mansfield Keeni wrote:
> Warren,Ignas,
>         Hi. The Security Guidelines for IETF MIB Modules
> needs a fix in the text that is generally used verbatim
> in MIB documents.
> The proposed fix is
> 
> OLD: Some of the readable objects in this MIB module
>       (i.e., objects with a MAX-ACCESS other than
>        not-accessible)
> NEW: Some of the readable objects in this MIB module
>       (e.g., objects with a MAX-ACCESS other than
>        not-accessible)
> 
> The above is a significant nit. It appears in the
> Security Considerations sections section of every
> MIB document.
> 
> There has been some discussion on the IETF MIB-DOCTORS
> mailing list on this matter. There is no disagreement
> on the proposed fix.

In the scope of the document under consideration at the
time, I think that fix was ok, but in the context of a
boilerplate update I think we'd need to do better.

For those who missed the original discussion, the issue is
that the values of "not-accessible" objects can
    (1) be sensitive
    (2) be revealed as index values

Consider, as a trivial, made-up example, a table indexed
by user name.

OLD:  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.

NEW:  Some of the objects in this MIB module may be considered sensitive
       or vulnerable in some network environments.  This includes INDEX
       objects with a MAX-ACCESS of not-accessible, and any indices from
       other modules exposed via AUGMENTS.

But, if we are going to touch the boilerplate, I wouldn't stop there.
I think the next sentence brings its own related problems.

OLD:  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.

The issues I see with this are:

    (1) in the case of objects used as indexes, controlling access to
        them via VACM is *not* just a matter of controlling access to
        the objects themselves, but of controlling access to all
        objects using them as indexes, including usage via AUGMENTS.

    (2) index values may be leaked by "pointer" objects of type
        OBJECT IDENTIFIER.  If VACM is being used for access control,
        the rules have to be formulated in terms of the pointer, not
        the set of things it might point to.  That problem is outside
        the scope of the module whose objects are being pointed to,
        but it's still a problem that needs to be addressed in any
        module defining such pointers.

    (3) even without considering the case of indexes, I would argue that
        if something is sensitive enough to merit limiting read access,
        in any sane security regime it will also merit encryption.  What
        is the point of limiting read access and then sending the
        information in the clear?

I'll concede that there are cases where limiting *write* access does not
imply a need for encryption, but this paragraph conflates sensitive and
vulnerable information.  It might make sense to split the paragraph into
two, one identifying the information for which disclosure is an issue,
and another identifying the information for which creation / deletion /
modification is an issue.

Randy