The Simple Network Management Protocol Version 3 (SNMPv3) addresses the security problems that have plagued both SNMPv1 and SNMPv2. For all practical purposes, security is the only issue SNMPv3 addresses; there are no other changes to the protocol. There are no new operations; SNMPv3 supports all the operations defined by Versions 1 and 2. There are several new textual conventions, but these are really just more precise ways of interpreting the datatypes that were defined in earlier versions.
This appendix provides an introduction to SNMPv3 and covers SNMPv3 configuration for a Cisco router and the Net-SNMP agent. Although SNMPv3 is not yet a full standard, a few vendors sell products with SNMPv3 support. We chose to cover two popular SNMPv3 implementations for our configuration examples.
The most important change is that Version 3 abandons the notion of managers and agents. Both managers and agents are now called SNMP entities. Each entity consists of an SNMP engine and one or more SNMP applications, which are discussed in the following sections. These new concepts are important because they define an architecture, rather than simply defining a set of messages; the architecture helps to separate different pieces of the SNMP system in a way that makes a secure implementation possible. Let's look at what these concepts mean, starting with the RFCs that define them (Table F-1).
|Name||Number||Status||Last Activity Date|
|Architecture for SNMP Frameworks||RFC 2571||Draft||April 1999|
|Message Processing and Dispatching||RFC 2572||Draft||April 1999|
|SNMP Applications||RFC 2573||Draft||April 1999|
|User-based Security Model||RFC 2574||Draft||April 1999|
|View-based Access Control Model||RFC 2575||Draft||April 1999|
|Protocol Operations for SNMPv2||RFC 1905||Draft||January 1996|
|Transport Mappings for SNMPv2||RFC 1906||Draft||January 1996|
|MIB for SNMPv2||RFC 1907||Draft||January 1996|
|Coexistence Between SNMP Versions||RFC 2576||Proposed||March 2000|
|Introduction to SNMPv3||RFC 2570||Informational||April 1999|
|Diffie-Hellman USM Key Management||RFC 2786||Experimental||March 2000|
The Message Processing Subsystem prepares messages to be sent and extracts data from received messages. A message processing system can contain multiple message processing modules. For example, a subsystem can have modules for processing SNMPv1, SNMPv2, and SNMPv3 requests. It may also contain a module for other processing models that are yet to be defined.
The Security Subsystem provides authentication and privacy services. Authentication uses either community strings (SNMP Versions 1 and 2) or SNMPv3 user-based authentication. User-based authentication uses the MD5 or SHA algorithms to authenticate users without sending a password in the clear. The privacy service uses the DES algorithm to encrypt and decrypt SNMP messages. Currently, DES is the only algorithm used, though others may be added in the future.
The Access Control Subsystem is responsible for controlling access to MIB objects. You can control what objects a user can access as well what operations she is allowed to perform on those objects. For example, you might want to limit a user's read-write access to certain parts of the mib-2 tree, while allowing read-only access to the entire tree.
|SnmpEngineID||An administratively unique identifier for an SNMP engine. Objects of this type are for identification, not for addressing, even though an address can be used in the generation of a specific value. RFC 2571 provides a detailed discussion of how SnmpEngineIDs are created.|
|SnmpSecurityModel||An SNMP securityModel (SNMPv1, SNMPv2, or USM). USM stands for User-based Security Model, which is the security method used in SNMPv3.|
|SnmpMessageProcessingModel||A Message Processing Model used by the Message Processing Subsystem.|
|SnmpSecurityLevel||The level of security at which SNMP messages can be sent, or the level of security at which operations are being processed. Possible values are noAuthNoPriv (without authentication and without privacy), authNoPriv (with authentication but without privacy), and authPriv (with authentication and with privacy). These three values are ordered such that noAuthNoPriv is less than authNoPriv and authNoPriv is less than authPriv.|
|SnmpAdminString||An octet string containing administrative information, preferably in human-readable form. The string can be up to 255 bytes in length.|
|SnmpTagValue||An octet string containing a tag value. Tag values are preferably in human-readable form. According to RFC 2573, valid tags include acme, router, and host.|
|SnmpTagList||An octet string containing a list of tag values. Tag values are preferably in human-readable form. According to RFC 2573, valid examples of a tag list are the empty string, acme router, and host managerStation.|
|KeyChange||An object used to change authentication and privacy keys.|
Copyright © 2002 O'Reilly & Associates. All rights reserved.