SNMPv3
The snmpV3 protocol is the newest addition to the SNMP family and is an
attempt to get the best of the various SNMPv2 variants and add to those
a better security system.
Unlike it's predecessor SNMPv2, SNMPv3 seem to be gaining acceptance
and has received backup from such network hardware manufacturers like Cisco,
Bay networks (Nortel) and others and from network management creators and
frameworks such as HP, and Tivoli(IBM)
Looking at SNMPv1 compared to SNMPv3 we see the following important
changes, most or all added to address specific problems in the SNMPv1 protocol.
Remote management of the SNMP agents
One of the major problems of SNMPv1 was the lack of options to remotely
manage the agents themselves, this was a result of the fact that agent
characteristics did not appear in any MIB and where, therefore, not accessed
by SNMP.
SNMPv3 therefore was designed with the ability to control the agents
Via use of a newly defined specific management MIB.
New data types
SNMPv3 did not really introduce any new data types but rather incorporated
the SNMPv2 data types.
The most notable ones added are the 64 bit counter solving the quick
wrap time encountered in some statistics and the bulk transfer options
used to enhance the efficiency of the transport of data.
Extensions to the MIB language
This is not, strictly speaking, a part of the new SNMPv3 protocol but is
needed to implement it.
Still many enhancements to the MIB definition language are created
based on ans.1 , these allow MIBs to include such things as the new security
definitions.
Security enhancements
This is where SNMPv3 is really different then the previous SNMP versions,
SNMPv1 only used the simplistic community string approach.
the community string was actually a password but it suffered from two
basic problems:
1. It was carried as clear text, making it completely vulnerable to
anybody with a packet capture software.
2. It could only allow or deny access to ALL components on the host,
there was no way to allow access to partial information only
SNMPv3 allows for a varied and complete security system.
The starting point for SNMPv3 where some basic decisions that caused
it to come out the way it did:
-
Not to employ an external server for authentication the way some OS like
NT goes about or the way the NIS system runs on some Unix system.
-
It was decided to keep all security information local to the host on
which SNMP is run, this is more like the Unix passwd file concept and means
any changes to security may need to be sent individually to each agent.
-
To ease administration of this system all the security parameters besides
the basic setup need to be enabled remotely.
-
To this end an administrator can set the basic security at installation
and then administer the security from some remote location, probably the
ENMS manager that manages the device in all other aspects.
-
Unlike SNMPv1 a more selective method of accessing information must be
created to allow different users to administer different parts (called
viewes) selectively on the device MIB.
-
Security must be defined in such a generic way that future security systems
can be phased in to the system , this resulted in the security subsystems
being kept outside the SNMP agents with appropriate API built to call them,
this way the security can be changed (and in the case of export restrictions
a restricted system can be used instead).
To achieve these goals a number of security subsystems where created:
Transport security subsystem, also referred to as User-based Security Model
(USM)
A Completely new, fully secure (or rather securable) system subject to
remote management was created as part of the SNMPv3 protocol suite.
The system uses the user/password pair paradigm and at present uses
only private key encryption.
All security data is kept on the host as stated above.
The system allows for the following services:
-
verification of data - achieved by using MD5 or SHA , prevents changing
the data on route.
-
verification of the identity of the generator - achieved by using MD5 or
SHA, prevents masquerading attacks
-
Ensure packet age - achieved by tracking timelines using timestamps, Defend
against message capture and replay.
-
Protection from disclosure - achieved by enabling full encryption of content,
the standard ways now are CDC/DES , prevents unauthorized users from gaining
data not allowed them.
View based access control system referred to as VACM (Views-Based Access
control Model)
The access control in SNMPv3 is based on the idea of a view - a subset
of the available MIB information kept on the host.
To be flexible the view system was defined in such a way that a view
can include another view, making it very easy to build new views.
The VACM defines a granular set of views, the groups allowed access
to the view and the type of access allowed from the following:
New system MIBs for security and agent management referred to as LCD
(local configuration database)
-
Security MIB - used to define the view based access control and the necessary
users, groups and group permissions.
-
The MIB is initialized for a new device with the administrator's parameter
and the global view and then the security can be remotely administered
by the defined administrators.
-
Management target MIB - Identification of Management Targets in Notification
Originators
-
Notification MIB - Notification Filtering at source to prevent unwanted
events from going out to the network.
-
Proxy MIB - Management Target Translation in Proxy Forwarder Applications.
Security management basics
On the way to being allowed rights on a MIB entity the following steps
are done:
-
The user is authenticated based on the authentication subsystem
-
The variable the user intends to access is matched to the view containing
it
-
The user's access rights are matched to the view access definitions to
check what type of access the user is granted.
-
If the user is allowed the access requested the request is handled.
This is captured in the following diagram:
Security Flow Chart
Last - we present some basic diagrams for the SNMP
entities (Previous diagram and those All directly taken from RFP's 2271-2275,
see specific details of entities there)
SNMP entity - general
| SNMP Entity |
| SNMP engine (identified by snmpEngineID) |
| Dispatcher |
Message Processing
Subsystem
(V1, V3 etc) |
Security Subsystem
(User based only today) |
Access control
subsystem.
(view based only today) |
| Applications |
| Command generator |
Notification receiver |
Proxy forwarder |
| Command responder |
Notification sender |
Other |
SNMP entity - manager (An example
may be a manager like OpenView)
SNMP entity - agent
References:
RFC's 2271-2275 at theRFC
repository
"Basking
in Glory-SNMPv3"
An article from Network Computing, Aug. 15, 1998.
SNMPv3 White
Paper
This document provides an introduction to the third version of the
Internet-Standard Management Framework.
SNMPv3
Issue of the Simple Times
Quarterly newsletter of SNMP Technology, Dec., 1997.