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