Re: [midcom] security recommendations in MIDCOM MIB draft
Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 12 July 2007 15:12 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 1I90LI-0003xC-1J; Thu, 12 Jul 2007 11:12:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90LG-0003uX-7E for midcom@ietf.org; Thu, 12 Jul 2007 11:12:30 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I90LB-0005EV-Gd for midcom@ietf.org; Thu, 12 Jul 2007 11:12:30 -0400
Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C33D9217FD; Thu, 12 Jul 2007 17:12:24 +0200 (CEST)
X-AuditID: c1b4fb3e-af833bb0000007e1-ae-469644d8c435
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A5E0E217ED; Thu, 12 Jul 2007 17:12:24 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 17:12:10 +0200
Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 13:51:13 +0200
Message-ID: <469615B1.6040309@ericsson.com>
Date: Thu, 12 Jul 2007 13:51:13 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Wes Hardaker <wjhns1@hardakers.net>
Subject: Re: [midcom] security recommendations in MIDCOM MIB draft
References: <6AFFE92CEE03A3E6C2E61771@753F3B888A9969457862729D> <468CD3FB.4040203@ericsson.com> <DEBABF6939AEF2CFE63C3811@juergen-quitteks-computer.local> <sdk5td1mpu.fsf@wes.hardakers.net>
In-Reply-To: <sdk5td1mpu.fsf@wes.hardakers.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Jul 2007 11:51:13.0538 (UTC) FILETIME=[F2692620:01C7C47A]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
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
Wes Hardaker skrev: >>>>>> "JQ" == Juergen Quittek <quittek@netlab.nec.de> writes: > > JQ> I don't think it would be appropriate to mandate in the MIDCOM MIB > JQ> draft a specific way of achieving a sufficient level of security. > > I believe the wording I've seen doesn't do this. It uses RECOMMENDED > and SHOULD to specify which particular implementation and deployment > details are the best at this time (and maybe adding "at the time of this > writing" is a good way forward as well). But, the important REQUIRED that > should stay a REQUIRED is this one: > > It is REQUIRED that the implementations support the security features > as provided by the SNMPv3 framework. > > Which merely says you must implement the security features in the > framework. I believe the framework implies "a security model" and "an > access control model", but not necessarily USM and VACM. The > recommendations for USM and VACM come in the next sentence, which is > relaxed to a RECOMMENDED to allow for other choices. > > It does also say that: > > In the draft, we explicitly state hat a MIDCOM MIB implementation > MUST support SNMPv3. > > That's the only protocol-secure alternative at this time at least, and > require implementations to support it makes sense. At this time. In > the future if netconf or some other new protocol has the ability to > access the MIDCOM MIB through a secure means, then it seems reasonable > to let them not implement SNMPv3. At this time, however, that's not > possible and SNMPv3 should be a MUST. Again, wording that allows for > future deviations is a way around this. Can we please come to consensus on this topic. And if there are text changes to implement the consensus, please provide them as RFC-editor notes to me. 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 ---------------------------------------------------------------------- _______________________________________________ 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