SNMPv2: Current Status and Future Outlook

Current Status and Future Outlook

by David Levi and David Partain
SNMP Research

October 1996

Distributed, multivendor networks can be configured in an unlimited number of ways; and while no two networks are alike, there is one thing that all distributed networks share in common: the need for improved manageability.

Ensuring security is a critical aspect of manageability.

Why Security?

As organizations increase their dependence upon internetworks and the World Wide Web (WWW) for conducting daily business, the issue of securing connected information technology (IT) assets climbs to the top of the MIS Director's short list of concerns.

Security today means much more than restricting access to the computer room. Hackers from without and disgruntled employees from within can access billions of dollars worth of sensitive information without leaving their desks. A comprehensive security pol icy must address the many forms of intrusion as well as identify which types of information are worth guarding.

Without question, network and systems management data is one of the most sensitive of all information types. Unauthorized persons with access to management data can not only discover an organization's network topology and computer asset placement, but also alter critical system parameters and bring a mission critical network to its knees.

Establishing firewalls is an important part of a security policy, but firewalls are not enough to secure management data. A comprehensive security policy requires implementation of the following security mechanisms at the protocol level:

authentication
privacy (encryption)
authorization
access control

The most widely used standard management protocol in use today is the Simple Network Management Protocol (SNMP). SNMP and related standards provide a common denominator for building management architectures in distributed multivendor networks. However, as deployed today, the original version of SNMP (SNMPv1) still falls short of meeting several important architectural requirements. For example, while effective management demands both monitoring and control facilities, SNMPv1 is still primarily used only for monitoring due to protocol's lack of security mechanisms. And when SNMP is deployed over the wide area without the use of intelligent agents and mid-level managers for localized polling and thresholding, traffic overhead may be excessive.

These and other issues prompted efforts to define SNMPv2. In December 1995, the IETF published the following SNMPv2 Request for Comments (RFCs), listed in Table 1.

**Table 1. Relevant SNMPv2 RFCs**
RFC Number	Title	Status
RFC 1901	Introduction to Community-based SNMPv2	Experimental Standard
RFC 1902	SMI for SNMPv2	Draft Standard
RFC 1903	Textual conventions for SNMPv2	Draft Standard
RFC 1904	Conformance statements for SNMPv2	Draft Standard
RFC 1905	Protocol operations for SNMPv2	Draft Standard
RFC 1906	Transport mappings for SNMPv2	Draft Standard
RFC 1907	MIB for SNMPv2	Draft Standard
RFC 1908	Coexistence between SNMPv1 and SNMPv2	Draft Standard

These RFCs include improvements for reducing SNMP traffic overhead and increase performance, such as the following:

GetBulk, a new operator allowing efficient retrieval of large blocks of data
64-bit counters, for instrumenting rapidly increasing variables such as octet counters in high-speed networks

In addition, the new specifications include transport mappings for using SNMP over Novell IPX, AppleTalk DDP, and OSI.

These improvements are good news for network and systems administrators looking to increase the efficiency of their management architectures. For example, performance gains from use of GetBulk can complement the move from centralized management to more di stributed schemes in which polling is localized through use of remote collection stations, intelligent agents, mid-level managers, and master agent/subagent systems. The ongoing efforts of the DISMAN Working Group to define Manager- to-Manager Communications will also help increasing the viability of distributed management architectures.

Security and an administrative framework were not defined in the SNMPv2 RFCs, however. Instead, these RFCs still rely on the older and weaker "Community" based concept of security; hence, these SNMPv2 RFCs are often collectively referred to as SNMPv2c.

Current Status of SNMPv2 Security

Because SNMPv2c did not settle outstanding questions on security or an administrative framework, the IETF formed an advisory committee that is now preparing a white paper describing the commonalities and differences between the two competing security/admi nistrative framework proposals, namely SNMPv2* and SNMPv2u. One purpose of the white paper is to suggest a compromise on those issues where v2* and v2u differ. The IETF is expected to activate the SNMPv2 working group at the December 1996 meeting in San J ose, California (USA).

SNMPv2*--Security and More

SNMPv2* builds upon the SNMPv2c foundation, adding critical aspects of security, administrative framework, and remote configuration. The security mechanisms supported by SNMPv2* are described in the Table 2.

Table 2. Security Mechanisms in SNMPv2*
Security Mechanism	How it Works	Its Purpose
Authentication with Digest	Verifies the identity of the message's origin; checks the integrity of the data	Thwarts "masquerade" attacks; detects if/when data has been modified
Authentication with Time-Stamping	Authenticates message stream integrity	Thwarts replay attacks
Privacy	Uses encryption to protect from disclosure	Prevents eavesdropping by protocol analyzers, etc.
Authorization	Using an Access Control Table, verifies whether or not the operator is authorized to read (get) or write (set) the requested MIB variable or variables	Supports policy-based management; operators see only what they need to see; protecting critical data from intentional and/or accidental corruption

Both SNMPv2* and SNMPv2u are "user-based,' in that user-based symmetric authentication is provided through the use of a digest-based authentication protocol with private keys and a monotonically increasing pair of time indicators.

To provide Authentication with Digest (as described in Table 1), SNMPv2* uses the Digest Authentication Protocol, which makes use of a message digest algorithm MD5, documented in RFC 1321. At the start of each SNMPv2* transaction, a portion of the SNMPv2 * message is run through the MD5 algorithm, producing a "fingerprint" or digest of the message. This fingerprint is compared by the message recipient to authenticate the user's identity and to verify that the message was not altered in transit.

Timestamping is provided by comparing local values for snmpBoots and snmpTime with the corresponding values (authSnmpBoots and authSnmpTime) received from the SNMPv2* message sender. For example, if the received value of authSnmpBoots is less than the local value of snmpBoots, the message is deemed "too old." Similarly, if the values of authSnmpBoots and snmpBoots are the same, but the value of authSnmpTime is more than 150 seconds less than snmpTime, the message is deemed "too old." This provides a 150 second window in which messages must arrive.

Occasionally, two communicating entities may get out of sync with one another. If that happens, SNMPv2* provides automatic mechanisms for resynchronization.

SNMPv2* defines a User-based Security MIB providing instrumentation that is unique to the user-based symmetric authentication and privacy service. The User-based Security MIB allows managers to add and delete users remotely with great ease, and to update their secrets. It also provides diagnostic counters for various error conditions.

Separating Authentication/Privacy from the Administrative Framework

The SNMPv2* design defines the overall structure of the administrative framework as multiple layers, consistent with good engineering principles.(1) This design follows the basic architecture of a separate authentication service, as outlined by the SNMPv1 specification (2).

SNMPv2* allows for several options with respect to authentication, including the following:

no authentication/no privacy
authentication without privacy
authentication with privacy

Privacy implies encryption. Use of DES for encryption is optional.

In SNMPv2*, the administrative framework is defined separately from the authentication service. The administrative framework defines services such as context selection and mechanisms for authorization and access and control.

An interesting and useful result of separating authentication from administrative framework is that SNMPv2* can take advantage of external authentication services, such as provided by secure HTTP and Secure Socket Layer (SSL), while still applying SNMPv2* services for authorization and access control.

The SNMPv2* Administrative Framework--Authorization and Access Control

Whereas SNMPv2* implements authentication on a per-individual basis, authorization is accomplished by associating an individual with a group that bears certain access control rights. Group names are site-dependent, and may include "helpdesk," "shiftsuperv isor," "root," and the like. Each group is authorized for certain types of operations, such as read/write, read/only, etc.

The greatest weakness of any security system is human involvement. Consequently, by automating as many aspects of remote configuration as possible, a set of security options can be made even stronger. Since older techniques for configuring management stat ions and agents require a tremendous amount of human involvement, security holes are not uncommon. SNMPv2* addresses some of these holes by fully describing the contents and capabilities of a local configuration datastore using the SNMP structure of management information (SMI). The official name of this MIB is the "Administrative MIB."

Outlook for SNMPv2 Security

Most industry observers anticipate that the IETF will not finish defining the SNMP security and administrative framework standards until late 1997 at best. In the meantime, SNMP Research International has been meeting customer demand for stronger security features with its Two-Star Security Pack for HP OpenView, and the more general-purpose Security Configuration Plus toolkit, which is included free in the Two-Star Security Pack. Both products are based on SNMPv2*, and support individual authentication an d policy-based (group profile) authorization and access control. Privacy and encryption options are included. Remote configuration of security parameters is simplified using the Security Configuration Plus GUI-based configuration facility.

The Two-Star Security pack consists of the following products:

the BRASS multilingual request subsystem--allows NNM to support secured communications via SNMPv2* while also handling SNMPv1 and SNMPv2c; BRASS also greatly simplifies the process of setting up SNMPv2* security configuration files
Security Configuration Plus--a graphical user interface (GUI) for creating/modifying SNMPv2* users and passwords from the OpenView NNM console
the EMANATE Master Agent--carries out requests from Security Configuration Plus by accessing and maintaining a local security configuration datastore
a Tcl scripting facility that runs under OpenView NNM

The Two-Star Security pack also supports two configuration datastores, one of which is used by the BRASS server and the other by the EMANATE Master Agent.

Two-Star Security provides several important benefits to NNM 4.1 customers:

Multifacted security management, including authentication, privacy, and authorization/access control
Supports SNMPv1, SNMPv2C, SNMPv2* simultaneously and transparently
Simplifies SNMPv2* security agent configuration files for all NNMs and SNMPv2* managed nodes
Hides details of SNMPv2* clock synchronization
Is sensitive to the memory constraints and ease-of-use requirements relevant to agents, management stations, and administrators

Two-Star Security is available now for HP OpenView NNM 4.1 on HP-UX 9.x, 10.x, and Solaris 2.x.

Security Can't Wait

Considering the recent explosion of Internet-based commerce along with the growing requirement to improve the manageability of connected systems, the need for security in management protocols has never been greater.

SNMPv2* provides strong security at the management protocol level, supporting both authentication and privacy. The administrative framework defined in SNMPv2* supports authorization, access control, context/naming of logical entities, and trap destination and configuration.

SNMPv2* is sensitive to the memory constraints and ease-of-use requirements relevant to agents, management stations, and administrators responsible for them. SNMPv2* was designed to preserve the vast customer investment in SNMP-based management, as well a s to make coexistence with and transition to these capabilities as smooth as possible.

The time is right for including strong security mechanisms and remote configuration of security parameters into the next generation of SNMP-based management facilities. Both SNMPv2* and SNMPv2u provide a good foundation upon which to complete this work. M any participants in the SNMPv2* effort are encouraged that the open process may soon be restarted and eventually lead to IETF standardization of missing aspects of the SNMPv2 management framework--namely security, an administrative framework, and a suitable remote configuration MIB.

For More Information:

The Internet Drafts specifying SNMPv2* can be found via the SNMPv2* Web site located at http://www.snmp.com/v2star.html.

To subscribe to the open SNMPv2* mailing list send a subscription request to snmpv2star-request@snmp.com.

To obtain information about commercially available security products such as Two-Star Security Pack and the Security Configuration Plus toolkit, send email to info@snmp.com or visit the SNMP Research International Web site at http://www.int.snmp.com.

Please send comments about our Web pages to: webmaster@int.snmp.com