Re: [midcom] security recommendations in MIDCOM MIB draft
Juergen Quittek <quittek@netlab.nec.de> Thu, 05 July 2007 18:36 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 1I6WBU-0002kb-Jj; Thu, 05 Jul 2007 14:36:08 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6W0Z-0008EF-Af for midcom@ietf.org; Thu, 05 Jul 2007 14:24:51 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6W0Y-0001ju-Ao for midcom@ietf.org; Thu, 05 Jul 2007 14:24:51 -0400
Received: from [192.168.1.144] (HSI-KBW-085-216-081-102.hsi.kabelbw.de [85.216.81.102]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 74BB413CF81; Thu, 5 Jul 2007 20:24:25 +0200 (CEST)
Date: Thu, 05 Jul 2007 20:24:29 +0200
From: Juergen Quittek <quittek@netlab.nec.de>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Subject: Re: [midcom] security recommendations in MIDCOM MIB draft
Message-ID: <DEBABF6939AEF2CFE63C3811@juergen-quitteks-computer.local>
In-Reply-To: <468CD3FB.4040203@ericsson.com>
References: <6AFFE92CEE03A3E6C2E61771@753F3B888A9969457862729D> <468CD3FB.4040203@ericsson.com>
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.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc: midcom@ietf.org, Tim Polk <tim.polk@nist.gov>
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
Using SNMPv3 is a good way (probably the best) to achieve the level of security required for the MIDCOM MIB. This is why the current draft says that all compliant implementations MUST support it. However, there are scenarios, where an operator may have good reasons for providing the required security by other means. Here are two potential reasons for doing so. - If you already run a logically or physically separated management network that is sufficiently secured against access from the operational network, it may be considered and overhead to also deploy SNMPv3. - Configuring SNMPv3 in a secure way is a complex task and can be really tricky. I did it already in the past and my memory of it is not a pleasant one. Also this is one of the core motivations for the work done in the ISMS WG. So, as an operator, running a few gateways implementing the MIDCOM MIB and a few SIP servers that configure the gateways using the MIDCOM MIB, it might be worth to think about whether to use SNMPv3 for securing it or to apply other means, such as a separate management network (or just secured tunnels between SIP servers and gateways). Sometimes it might be - easier - less error-prone - better matching the skill set of the acting network administrators not to use SNMPv3 (or use SNMPv3 with security disabled), but deploy other means. Even though saying this, I would not like to add a recommendation to the draft stating that in some situations is would be better to provide other means for securing the MIDCOM MIB. I see these scenarios rather as exceptions that may occur and a discussion of other means might be misleading for many readers. But the security considerations section in the drafts leaves the door open to alternatives by just stating "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." Please consider also that there are many ways to configuring SNMPv3 security. For example, a security model needs to be chosen. The currently dominating one is the User-based Security Model (USB), but others are under development, for example in the ISMS WG. I don't think it would be appropriate to mandate in the MIDCOM MIB draft a specific way of achieving a sufficient level of security. Thanks, Juergen --On 05.07.07 13:20 +0200 Magnus Westerlund wrote: > Juergen Quittek skrev: >> 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? >> > > To make sure I understand this correctly. Without SNMPv3 and its security functions the MIDCOM MIB will not reach the security requirements identified? If this is true, I think it is quite clear that MIDCOM MIB should only be used with SNMPv3. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- -- 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
- [midcom] security recommendations in MIDCOM MIB d… Juergen Quittek
- Re: [midcom] security recommendations in MIDCOM M… Lars Eggert
- Re: [midcom] security recommendations in MIDCOM M… Lars Eggert
- Re: [midcom] security recommendations in MIDCOM M… Magnus Westerlund
- Re: [midcom] security recommendations in MIDCOM M… Juergen Quittek
- Re: [midcom] security recommendations in MIDCOM M… Wes Hardaker
- Re: [midcom] security recommendations in MIDCOM M… Magnus Westerlund
- Re: [midcom] security recommendations in MIDCOM M… Melinda Shore
- Re: [midcom] security recommendations in MIDCOM M… Wes Hardaker
- Re: [midcom] security recommendations in MIDCOM M… Melinda Shore
- Re: [midcom] security recommendations in MIDCOM M… Wes Hardaker