[midcom] security recommendations in MIDCOM MIB draft

Juergen Quittek <quittek@netlab.nec.de> Tue, 03 July 2007 18:53 UTC

Return-path: <midcom-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5nVG-000716-69; Tue, 03 Jul 2007 14:53:34 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5mx2-0004qf-GY for midcom@ietf.org; Tue, 03 Jul 2007 14:18:12 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5mwo-0007xG-NY for midcom@ietf.org; Tue, 03 Jul 2007 14:18:01 -0400
Received: from localhost (kobe.netlab.nec.de [195.37.70.60]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 468D513CF82; Tue, 3 Jul 2007 20:17:49 +0200 (CEST)
Date: Tue, 03 Jul 2007 13:33:21 +0200
From: Juergen Quittek <quittek@netlab.nec.de>
To: midcom@ietf.org
Message-ID: <6AFFE92CEE03A3E6C2E61771@753F3B888A9969457862729D>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: Tim Polk <tim.polk@nist.gov>
Subject: [midcom] security recommendations in MIDCOM MIB draft
X-BeenThere: midcom@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: midcom.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=subscribe>
Errors-To: midcom-bounces@ietf.org

Dear all,

The MIDCOM MIB is progressing and currently under IESG review.
Tim Polk made a comment that I would like to discuss here on this list.

In the draft, we explicitly state hat a MIDCOM MIB implementation
MUST support SNMPv3.  However, we pass the responsibility of switching
on SNMPv3 to the operator.  The operator may still run SNMPv1 or SNMPv2
if security is provided otherwise:

  "Compliant MIDCOM MIB implementations MUST support SNMPv3 security
   services including data integrity, data origin authentication and
   data confidentiality.

   It is REQUIRED that the implementations support the security features
   as provided by the SNMPv3 framework.  Specifically, the use of the
   User-based Security Model RFC 3414 [RFC3414] and the View- based
   Access Control Model RFC 3415 [RFC3415] is RECOMMENDED.

   It is then a customer/operator responsibility to ensure that the SNMP
   entity giving access to an instance of this MIB, is properly
   configured to give access to the objects only to those principals
   (users) that have legitimate rights to indeed GET or SET
   (change/create/delete) them."

Now, Tim suggests to explicitly deprecate the use of (insecure) previous
versions of SNMP, for example with a phrase like

  "Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED.
   Instead it is RECOMMENDED to deploy SNMPv3 and to enable
   cryptographic security."

Are there any opinions about adding such a phrase to the security
considerations?

Thanks,

    Juergen
-- 
Juergen Quittek        quittek@netlab.nec.de       Tel: +49 6221 4342-115
NEC Europe Limited,    Network Laboratories        Fax: +49 6221 4342-155
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de
Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK
Registered in England 2832014



_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom