[secdir] SecDir review of draft-ietf-opsawg-syslog-msg-mib-04

Magnus Nyström <magnus@rsa.com> Mon, 20 July 2009 15:30 UTC

Return-Path: <magnus@rsa.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA0B28C18F; Mon, 20 Jul 2009 08:30:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmfiHdRayGu9; Mon, 20 Jul 2009 08:30:01 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 9C4AC3A6C9B; Mon, 20 Jul 2009 08:29:27 -0700 (PDT)
Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id n6KFTOGh000795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2009 11:29:24 -0400
Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si04.isus.emc.com (Tablus Interceptor); Mon, 20 Jul 2009 11:29:17 -0400
Received: from corpussmtp2.corp.emc.com (corpussmtp2.corp.emc.com [128.221.14.146]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n6KFTClT022690; Mon, 20 Jul 2009 11:29:16 -0400
Received: from CORPUSMX50B.corp.emc.com ([128.221.62.39]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 11:29:14 -0400
Received: from W-JNISBETTEST-1 ([10.100.100.103]) by CORPUSMX50B.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 11:29:14 -0400
Date: Mon, 20 Jul 2009 11:29:35 -0400
From: Magnus Nyström <magnus@rsa.com>
To: iesg@ietf.org, secdir@ietf.org, secdir-secretary@mit.edu, j.schoenwalder@jacobs-university.de, alex@cisco.com, akarmaka@cisco.com, sob@harvard.edu, ted.a.seely@sprint.com
In-Reply-To: <Pine.WNT.4.64.0906142309020.632@W-JNISBETTEST-1.tablus.com>
Message-ID: <Pine.WNT.4.64.0907200900100.6844@W-JNISBETTEST-1.tablus.com>
References: <Pine.WNT.4.64.0805121031000.2612@W-JNISBETTEST-1.tablus.com> <Pine.WNT.4.64.0811051802030.7640@W-JNISBETTEST-1.tablus.com> <Pine.WNT.4.64.0812101529200.3888@W-JNISBETTEST-1.tablus.com> <Pine.WNT.4.64.0902161338530.5224@W-JNISBETTEST-1.tablus.com> <Pine.WNT.4.64.0905032241410.5248@W-JNISBETTEST-1.tablus.com> <Pine.WNT.4.64.0906142309020.632@W-JNISBETTEST-1.tablus.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-OriginalArrivalTime: 20 Jul 2009 15:29:14.0272 (UTC) FILETIME=[D6680200:01CA094E]
X-EMM-EM: Active
Subject: [secdir] SecDir review of draft-ietf-opsawg-syslog-msg-mib-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 20 Jul 2009 15:30:03 -0000

I have reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG. These 
comments were written primarily for the benefit of the security area 
directors.  Document editors and WG chairs should treat these comments just 
like any other last call comments.

Background
----------
This document defines a MIB module for use when mapping SYSLOG messages to 
SNMP notifications.

Comments
--------

- In the SYSLOG-MSG-MIB module, the syslogMsgSDTable is defined with the
   syntax

   SEQUENCE OF SyslogMsgSDEntry

   Would it make sense to restrict this with an upper (and perhaps lower)
   bound to reduce the risk of either non-interop or potential attacks?
   E.g. like

   SEQUENCE SIZE (1..<upper-bound>) OF SyslogMsgSDEntry

   where <upper-bound> is replaced with something reasonable?

- (Editorial) In the Security Considerations section, there is a paragraph
   recommending against deployment of earlier versions of SNMP. For
   clarity and correctness ("NOT RECOMMENDED" is not a key word) I suggest
   this paragraph is rewritten to (several changes in the below):

    Further, SNMP versions prior to SNMPv3 SHOULD NOT be deployed.
    Instead, SNMPv3 with enabled cryptographic security SHOULD be deployed.
    It is then a customer/operator responsibility to ensure that the SNMP
    entity giving access to an instance of this MIB module is properly
    configured to give access to the objects only to those principals
    (users) that indeed have legitimate rights to GET or SET
    (change/create/delete) them.

-- Magnus