Subject: [midcom] security recommendations in MIDCOM MIB draft

From: Juergen Quittek <[email-masked]>
Date: Tue, 03 Jul 2007 13:33:21 +0200

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        [email-masked]       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
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Lars Eggert <[email-masked]>
Date: Wed, 4 Jul 2007 09:29:51 +0300

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

This is a general applicability statement on the use of various SNMP  
versions and extensions, which IMO isn't for MIDCOM to make, at least  
not without prior review by the OPS area. But given the well-known  
problems with older versions of SNMP, maybe there already is a  
statement by the OPS area to that effect that the MIDCOM draft can  
simply point to?

Lars

---

From: Lars Eggert <[email-masked]>
Date: Wed, 4 Jul 2007 09:49:31 +0300

On 2007-7-4, at 9:43, ext Romascanu, Dan (Dan) wrote:
> So, I am not sure that I see the problem. The MIDCOM MIB document  
> seems
> to be OK in adopting a strict secure mode SNMPv3 requirement.

There is not a problem then. I just wanted to make sure that the  
MIDCOM MIB doesn't make statements it shouldn't make.

> If we need
> to discuss a change in the security considerations for other MIB
> documents we should discuss this separately.

No, that's not what this was about.

Thanks!

Lars

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 05 Jul 2007 13:20:27 +0200

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

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: [email-masked]
----------------------------------------------------------------------

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 05 Jul 2007 20:24:29 +0200

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

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:

> 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
>

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 06 Jul 2007 10:11:25 -0700

>>>>> "JQ" == Juergen Quittek <[email-masked]> 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:

  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.
-- 
Wes Hardaker
Sparta, Inc.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 Jul 2007 13:51:13 +0200

> 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

---

From: Melinda Shore <[email-masked]>
Date: Thu, 12 Jul 2007 11:40:15 -0400

> changes to implement the consensus, please provide them as RFC-editor

The starting point is: requesting services from a middlebox must
be secure.  If that's to be done cryptographically, it requires
SNMPv3.  If it's not to be done cryptographically it suggests that
the protocol is being run over a "secure" network.  The latter was
not considered acceptable by the responsible area director at the
time that the work was ramping up, and it seems to me the question
of whether or not SNMPv3 is to be required hinges on whether or
not we can now permit an assumption of a "secure" network (for example,
running it over an IPSec tunnel).  It seems to me that if we
can't assume the use of a secure network in some deployments then
SNMPv3 has to be required, since sending firewall requests and
NAT answers insecurely is obviously unacceptable.  Do you think
the assumption of a secure network would pass review?

Melinda

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 13 Jul 2007 06:58:03 -0700

>>>>> "MS" == Melinda Shore <[email-masked]> writes:

>> changes to implement the consensus, please provide them as RFC-editor

MS> The starting point is: requesting services from a middlebox must
MS> be secure.  If that's to be done cryptographically, it requires
MS> SNMPv3.

I think the text needs to require one method be available to operators
consistently across all the devices they purchase.  If they choose not
to use it because they have other methods of securing their traffic
they're comfortable with, then so be it.  But at least they should be
sure they can use one method.

Something like:

MIBCOM devices MUST implement SNMPv3 to allow for operators to rely on
it's features in order to protect their traffic.  Operators should use
make use of SNMPv3, other protocols providing cryptographic protection
or physical separation to to ensure MIBCOM traffic is secured.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Melinda Shore <[email-masked]>
Date: Fri, 13 Jul 2007 10:39:10 -0400

> or physical separation to to ensure MIBCOM traffic is secured.

Yes, that's pretty much where I am, too (note that it's actually
"midcom," although "mibcom" is a pretty great portmanteau jobbie).

Melinda

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 13 Jul 2007 12:56:53 -0700

>> or physical separation to to ensure MIBCOM traffic is secured.

MS> Yes, that's pretty much where I am, too (note that it's actually
MS> "midcom," although "mibcom" is a pretty great portmanteau jobbie).

Drat (I know that of course).  You know I fixed that a few times before
rearranging what I was saying again?  You can tell what 3 letter acronym
I type too often ;-)

sigh...
-- 
Wes Hardaker
Sparta, Inc.