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

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 protected]
co-chair SNMPv3 WG, concluded


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

>>>>> On Tue, 21 Sep 2004 16:16:25 +0300 (EEST), Pekka Savola
<[email protected]> 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