Subject: Re: [ipcdn] draft-ietf-ipcdn-device-mibv2-01.txt

From: RJ Atkinson <[email-masked]>
Date: Mon, 22 Apr 2002 14:23:42 -0400

On Monday, April 22, 2002, at 01:24 , Andy Bierman wrote:

> At 03:27 AM 4/22/2002, Wijnen, Bert (Bert) wrote:
>> I am working on a revised text for the guideline.
>
> I object to the last statement in Ran's text proposal.
> It is one thing to point out the security vulnerabilities
> of SNMPv1 and SNMPv2c, but it is another thing to mandate
> the use of SNMPv3 (in the boilerplate section of a MIB
> document.)

My text does not mandate "use" but does mandate "implementation".
So my draft text places a burden on implementers/vendors,
but does not tell operators how to deploy their equipment.

That distinction is critical, IMHO.

> I do not object to mandating specific functionality.
> I object to mandating a specific solution for achieving
> that functionality.

	IETF standards are entirely about mandating specific
solutions (namely: IETF standards) for achieving
particular functions.  In this case, SNMPv3 is the
IETF standard approach to providing cryptographic
protection for SNMPv3 and for MIBs.

	So maybe I don't grok your objection.

> This statement seems to suggest that implementations must differentiate
> operations by security user (i.e., use VACM and USM).
> I think such features should not be mandated. SNMPv1(2c) over IPSEC 
> should
> be considered secure enough.

	Not hardly secure enough, though I know that cisco is trying to
push that approach so they can sell a more proprietary approach
to SNMP and MIB security for their own profit reasons.

	Oh, and that text came out of a published IETF standards-track
MIB's security considerations text (already an RFC long since).
So I borrowed it from another author, credit where due.

Ran
[email-masked]

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 22 Apr 2002 14:23:42 -0400

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 22 Apr 2002 16:50:56 -0400

On Monday, April 22, 2002, at 03:17 , Andy Bierman wrote:

> At 11:23 AM 4/22/2002, RJ Atkinson wrote:
>
>>> ...
> Please explain why IPSEC is not secure enough,

	Does not provide the right security properties,
particularly in the key management arena, but also in
other areas.  IPsec was not designed to secure SNMP
-- it was designed to provide a different set of properties.

	I'm modestly familiar with IPsec, having invented it,
chaired the WG in the past, and having worked on an
early implementation of it.  So it should bother folks
when I suggest that IPsec is not well suited to protecting
SNMP network management.  Saying "just use IPsec" is an
increasingly common cop-out for folks unwilling (for whatever
reason) to actually address the security needs of particular
protocols.

> why multiple security users per application are mandatory,

	The ability to grant different levels of access to different
users is long-standing in SNMP and would be lost by just using
SNMP/IPsec.  Many examples exist of this.  There is VERY broad
agreement in the network management community that multiple
user support is a requirement and this agreement dates back
at least a decade.

	One example is that we have a system where I should have
read-only access to the MIBs, but another person should have
read-write access to the MIBs.  With SNMP/IPsec, this box cannot
be deployed by me as an operator and provide that property.
There are other defects of SNMP/IPsec in terms of the provided
security properties as compared with SNMPv3.

	The requirement is on *implementations* of SNMP, so that
operators can use the capability (or not use it) as the operator
prefers.

> and why IPSEC is proprietary.

	SNMP/IPsec is proprietary to cisco as are several other foo/IPsec
approaches that cisco is selling.   Even if it provided the right
security properties (which it doesn't), one needs a separate *spec* for
SNMP/IPsec, because that by itself isn't even clear in what
is being used.  Possible values for that phrase include at least:

1st axis:		(SNMP/AH, SNMP/ESP-auth-only, SNMP-auth-encrypt)
2nd axis:		authentication algorithms (MD5, HMAC MD5, SHA-1, HMAC 
SHA-1, others)
3rd axis:		confidentiality algorithms (DES-CBC, 3DES-2key, 3DES-3key, 
AES-CBC, others)
3rd axis:		key management protocol in use (and which of its
			algorithms, modes, initialisation methods, etc.)

	IKE, by itself, has a very large set of possible configurations
-- so many that it is not in fact interoperable amongst independent
implementations, which is one reason the IPsec WG plans to replace
it with (either IKEv2, which is different, or JFK, or something else).

	Ignoring IKE, there are at least (3 * 5 * 5 = 75) meanings of
"SNMP/IPsec".  If one adds in IKE (or another less openly specified
key management mechanism), one easily is into large hundreds or
even thousands of combinations that could each mean "SNMP/IPsec".

	How is this *interoperable* with anyone other than cisco ?
Answer, it is not without an open IETF spec, so it is a *proprietary* 
approach.

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 22 Apr 2002 16:50:56 -0400

Ran
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Apr 2002 10:24:16 -0700

I object to the last statement in Ran's text proposal.
It is one thing to point out the security vulnerabilities
of SNMPv1 and SNMPv2c, but it is another thing to mandate
the use of SNMPv3 (in the boilerplate section of a MIB
document.)  In any case, such important normative text
should not be buried in the intro section of each MIB.

The following boilerplate statement seems to mandate features
not required for security:

  SNMPv1 by itself is not a secure environment.  Even if the network
  itself is secure (for example by using IPSec), even then, there is no
  control as to who on the secure network is allowed to access and
  GET/SET (read/change/create/delete) the objects in this MIB.

This statement seems to suggest that implementations must differentiate
operations by security user (i.e., use VACM and USM).
I think such features should not be mandated. SNMPv1(2c) over IPSEC should
be considered secure enough.

>Bert 

Andy

>> -----Original Message-----
>> From: RJ Atkinson [mailto:[email-masked]]
>> Sent: Thursday, April 18, 2002 7:13 PM
>> To: Woundy, Richard
>> Cc: [email-masked]'; IPCDN (E-mail)
>> Subject: Re: [ipcdn] draft-ietf-ipcdn-device-mibv2-01.txt
>> 
>> 
>> 
>> On Thursday, April 18, 2002, at 12:59 , Woundy, Richard wrote:
>> 
>> > Folks,
>> >
>> > The current Security Guidelines uses the following text to 
>> warn against
>> > using SNMPv1:
>> >
>> >    SNMPv1 by itself is not a secure environment.  Even if 
>> the network
>> >    itself is secure (for example by using IPSec), even 
>> then, there is no
>> >    control as to who on the secure network is allowed to access and
>> >    GET/SET (read/change/create/delete) the objects in this MIB.
>> >
>> > Shouldn't this text also point out that SNMPv2c suffers 
>> from the same
>> > security vulnerabilities? Note that SNMPv2c is explicitly 
>> mentioned in 
>> > the
>> > standard MIB boilerplate 
><http://www.ops.ietf.org/mib-boilerplate.html>.
>
>        Thanks.
>
>MIB Folks,
>
>        It should also explicitly note that SNMPv1 and SNMPv2c both use 
>clear-text
>disclosing passwords -- which are not considered to provide acceptable
>security for an IETF protocol.
>
>        We need to start having MIBs mandate that implementers implement
>SNMPv3 now that has advanced to Full Standard, IMHO.
>
>Ran

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Apr 2002 12:17:54 -0700

>to SNMP and MIB security for their own profit reasons.

Please explain why IPSEC is not secure enough, why multiple security
users per application are mandatory, and why IPSEC is proprietary.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Apr 2002 12:17:54 -0700

Andy