Subject: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)]

From: Pekka Savola <[email-masked]>
Date: Tue, 21 Sep 2004 16:16:25 +0300 (EEST)

Hi,

[note: I'm not subscribed on either list]

Now that the IESG has approved the isms WG, it might be OK for me to 
raise one particular issue which is slightly off-topic but might be 
worth bringing up in order to make sure that it's adequately 
addressed.

That is, I haven't found (granted, I haven't tried looking hard) a
concise statement(s) to the question that's relevant to many operators
(including the NREN/ISP I'm associated with):

   What benefits does SNMPv3 offer to us, compared to our use of 
   SNMPv1 and SNMPv2?

The isms WG problem statement (below) brings up two problems with
access controls, but it is not clear whether these are the only two
(major) reasons for using SNMPv3 instead of SNMPv1/2.

It is important to figure out the answer to this question so that we
don't misinterpret why many operators are not using SNMPv3 and the
security model (below).

On Wed, 8 Sep 2004, The IESG wrote:
> A new IETF working group has been proposed in the Security Area. The IESG has not made 
> any determination as yet. The following description was submitted, and is provided 
> for informational purposes only. Please send your comments to the IESG mailing list 
> ([email-masked]) by September 15. 
> 
> Integrated Security Model for SNMP (isms)
> =========================================
> 
> Current Status: Proposed Working Group
> 
> Description of Working Group:
> 
> Version 3 of the Simple Network Management Protocol (SNMPv3) was
> elevated to Internet Standard in late 2002 and added security to the
> previous versions of the protocol. Although the enhanced protocol
> is secure, operators and administrators find that deploying it can
> be problematic in large distributions. This is due primarily to two
> synchronization problems. The first is the addition of yet another
> authentication system specific to SNMPv3 that needs to be maintained
> across all networking devices. Most of these devices already
> contain local accounts and/or the ability to negotiate with
> authentication servers (e.g. RADIUS servers). However, SNMPv3 does
> not make use of these authentication mechanisms, and this causes
> additional synchronization burdens. The second issue found with
> deploying SNMPv3 is that distributing and maintaining View-based
> Access Control Model (VACM) rules is also difficult in large-scale
> environments.
[...]

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 22 Sep 2004 06:57:19 -0700

>>>>> On Tue, 21 Sep 2004 16:16:25 +0300 (EEST), Pekka Savola <[email-masked]> said:

Pekka> What benefits does SNMPv3 offer to us, compared to our use of 
Pekka> SNMPv1 and SNMPv2?

Security?  That's the primary achievement of SNMPv3 over anything
previous.  SNMPv1 and SNMPv2c aren't even close to secure.  SNMPv3 is,
albeit with some of the deployment problems that ISMS is hoping to
fix.  SNMPv3 contains other miscellaneous improvements as well (max
msg size specification, ...)

-- 
Wes Hardaker
Sparta

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 22 Sep 2004 11:49:36 -0400

Hi,

As Wes point sout, SNMPv3 provides security enhancements, but I think
we need to be more specific. 

1) SNMPv3 provides an application-level authentication of the security
principal. 

I could just run SNMPv1 over IPSec and have "security". But as Jeff
Schiller's Sunday Security presentation points out, "just use IPSec"
isn't good enough as an answer. One needs to understand how SNMP has
bindings to any underlying security mechanisms. That fact is, there
are no bindings to an SNMP application (agent/manager) because, at
this point, an underlying IPSec, SSH, TLS, VPN, or whatever does not
identify an authenticated application-layer security principal that
SNMP can use to apply access control. 

2) SNMPv3 USM provides robust authentication of a security principal.

Do operators want user-level access control? They have user-level
authentication in SSH to control access to the CLI. Most web-based
device configuration tools require some sort of user-based
authentication to control who has access. So it appears that
user-level authentication is desired to control who is granted access
to the management interface. But the CLI, web-based mgmt, and
SNMP-based mgmt all control the same underlying instrumentation. If
SNMP (or CLI or web-based or Netconf or ....) doesn't provide a
comparable level of authentication for access, then an attacker can
simply select the management interface with the weakest security to
gain access to the underlying instrumentation. The security of the
different interfaces need to be balanced. Ideally, they might share a
common authentication mechanism.

SNMPv1 and SNMPv2 do not provide this beyond the trivial
authentication provided by community strings, and since these ar
epassed in cleartext, they really provide no security. SNMPv3 USM
provides robust authentication of a security principal.

I deliberately say security principal rather than user because many
organizations configure their devices to permit a trusted application
to have access. For example, Spectrum has a user login to the
application, and Spectrum is a USM security princiapl in many devices.
The manager application aggregates the requests of many users. For
another example, many applications actually don't support SNMPv3; they
use local SNMPv1 or IPC to talk to a daemon that converts the request
into the secure SNMPv3 format, and the daemon is a security principal
at the managed device. I raise this only because in these cases,
operators apparently do NOT care if the operator is authenticated. If
the CLI,web,Netconf interfaces provided manager-level authentication,
and the manager interface aggregated services for authenticated users,
then all the interfaces could be balanced. I don't know whether this
is adeqaute for all operators, but it apparently is adequate for some.

3) SNMPv3 provides access control over the principal's data-level
authorization

SNMPv3 provides per-principal control over what operations can be
performed, to which datasets (contexts or communities), to which mib
modules within the data set, and to which subtrees of the dataset (all
the way down to the object level if desired). SNMPv1 and SNMPv2 cannot
provide this because they cannot provide authentication of the
principal, and without an authenticated principal, the additional
controls make no sense.

Do operators want user-level access control to different portions of
the management data? We were told by the operators, especially Mike
O'Dell, that it was critically important functionality. Mike O'Dell
told us UUNET would refuse to buy products that did not have this
functionality.

CLIs and web-based mgmt tools often provide per-user task-based
authorization functionality for those management interfaces. For
applications that are confiured as an SNMPv3 security principal, the
manager typically provides thi slevel of access control within the
application, because customers demand this type of per-user access
control to datasets/modules/objects, etc.

Do operators want this functionality or not? I suspect different
operators have different levels of authroization (and user
aggregation) they find useful, which depends on the companies they
work for and the environment in which they operate.

SNMPv3 can provide this functionaity; SNMPv1 and SNMPv3 do not. If
SNMP doesn't provide this, while the CLI and web-based interfaces do,
then the security of the management infrastructure is weakened across
the board.

--
Those are the major features provided by SNMPv3 that are not provided
by SNMPv1 and SNMPv2. 

It is important that these features be present in SNMP to provide
balanced security with the other common management interfaces.

David Harrington
[email-masked]
co-chair SNMPv3 WG, concluded

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Wes Hardaker
Sent: Wednesday, September 22, 2004 9:57 AM
To: Pekka Savola
Cc: [email-masked]; [email-masked]
Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model
for SNMP (isms)]

--
Wes Hardaker
Sparta