[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [midcom] security recommendations in MIDCOM MIB draft

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 at ericsson.com
----------------------------------------------------------------------




--
Juergen Quittek        quittek at 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 at ietf.org
https://www1.ietf.org/mailman/listinfo/midcom