The USEC Resource Page

Welcome to The USEC Resource Page.

This page's goal is to provide information about the status of the User-based Security Model (USEC, aka SNMPv2u), which adds strong security and a no-frills administrative infrastructure to the SNMPv2 framework.

Recent changes to this page:

This page describes:

For an overview of USEC and SNMP security, you might consult this white paper. Alternatively, if you're not familiar with why SNMPv2 did a crash and burn, you can read this history, which, in the author's opinion, is less self-serving than revisionist history.


The USEC specification has been published as an experimental protocol. At present, the IETF has produced one other administrative infrastructure for SNMPv2, also experimental, which uses the community-based, administrative model from SNMPv1.


The USEC specification consists of two documents: Since publication, we've found a couple of typos in RFC 1910:
Page 20, Section 3.1, Step (8):
Original text:
(8) If the qoS specifies that the message is to be authenticated, then an MD5 digest value is computed over the octet sequence representing the concatenation of the serialized Message value and the user's authentication key. The <authDigest> field is then set to the computed digest value.
Corrected text:
(8) If the qoS specifies that the message is to be authenticated, then a digest value is computed over the octet sequence representing the concatenation of the serialized Message value and the user's authentication key according to the user's authentication protocol. The <authDigest> field is then set to the computed digest value.
Page 22, Section 3.2, Step (9), Clause c):
Original text:
c) if the LCD information indicates the SNMPv2 context is of type local (i.e., an agent), then:
Corrected text:
c) if the LCD information indicates the SNMPv2 context is of type local or local-proxy (i.e., an agent), then:

For your reference, the SNMPv2 framework consists of these documents:

At the 35th meeting of the IETF

The IETF's Area Director for Network Management, Deirdre Kostick, held an area meeting to discuss progress in SNMPv2 security. Presentations were made on both SNMPv2u and SNMPv2*.

Glenn Waters presented a status report on SNMPv2u, whilst Bert Wijnen presented a comparison between SNMPv2* and SNMPv2u. In addition, Jeff Case made a presentation on SNMPv2* along with his own comparison with SNMPv2u. Glenn and Bert have written a detailed technical response to Jeff's presentation.

What's Next

The USEC specification provides a stable, minimalist platform that exhibits core competency in strong security. It is now time to study how remote configuration can be sanely added to this base. This topic is being described on an open mailing list, which you can subscribe to.

Recent Events

USEC BOF at N+I Vegas '96

A ``Birds of a Feather'' session on USEC was at NetWorld+Interop '96 in Las Vegas Nevada. For more information, consult this release.

In addition, USEC gained some momentum at N+I Vegas '96. For more information, consult this release.

USEC Demonstration at ComNet '96

At Comnet '96, there was a USEC demonstration of some of the independently-developed, interoperable USEC-compliant implementations listed below. For more information, consult this release and this fact sheet.


All of the commercial and openly-available implementations listed here have been undergone interoperability testing with each other. Although authentication has been uniformly tested, only some of the implementations support privacy; however, this subset was tested for interoperable behavior when communicating encrypted traffic.

Commercial Implementations

Epilogue Technology

Epilogue currently offers a family of products to computer software and hardware companies that allow them to add SNMP support to their LAN, WAN, and computer products, including: The current version (6.0) of Envoy supports both SNMPv1 and (the now historical) SNMPv2 classic. The next version will drop SNMPv2 classic and add SNMPv2c. As part of our continuing support of the IETF, we have also implemented SNMPv2u in order to help refine the protocol. Our implementation supports authentication but, due to export control restrictions, not privacy.

IBM SystemView for AIX

The IBM Netview for AIX feature of SystemView provides distributed or centralized management of large heterogeneous networks. Features include Network Configuration, Platform Security, Dynamic Device Discovery, a Graphical User Interface with client/server distribution, and many other functions. Netview for AIX is an integreal feature of the SystemView for AIX product which is esay to install and use. SystemView is key to IBM's strategy for open system's management. A white paper describing SNMPv2 support in IBM SystemView is available.

As part of its continued support for industry standards and directions, Netview for AIX V4R1 feature has introduced a new library for performing SNMP communications based upon the WinSNMP/Manager Open Interface for Programming V1.1a. Features of the new API include transparent support for SNMPv1, SNMPv2c, and SNMPv2u (USEC). IBM Netview for AIX SNMPv2u support will include message authentication but not privacy at this time due to US export regulations. In addition to the new API, Netview feature also contains a SNMPv1, SNMPv2c, SNMPv2u-enabled MIB Browser and MIB Compiler/Loader!

Openly-Available Implementations


The CMU v1.1b SNMP agent written by Steve Waldbusser, has been modified to add support for the User-based Security Model (SNMPv2u). Included in the source code distribution are: The software does not support privacy at present due to export control regulations. Support for SNMPv2c will be added to the agent in the near future.


NetSCARF is a Network Statistics Collection and Reporting Facility. It allows ISPs to collect and report data about their part of the Internet.

Version 1.1 of NetSCARF supports both SNMP version 1 and USEC. The NetSCARF implementation of USEC supports authentication and privacy; however, at present the code which implements privacy, while tested with many of the other implementations listed here, is unavailable for release.


Scotty is a network management extension for the Tool Command Language (Tcl) which includes a portable implementation of the SNMPv1, SNMPv2c and SNMPv2u protocol. The SNMP implementation supports USEC authentication without privacy and includes a manager and an agent API.

Version 2.1.0 of the Scotty Tcl extension is based on Tcl7.5/Tk4.1 and runs under UNIX/X11. Work on a port to the Windows NT platform has started. The Scotty Tcl extension includes the network management platform (Tkined) which provides a MIB browser, a network map editor as well as status monitoring, troubleshooting, network discovery and event filtering scripts.

Discussions about the Scotty Tcl extension take place on the tkined mailing list.


snmptcl v1.3 is a extensible platform for management applications which seemlessly implements SNMPv1, SNMPv2c, and SNMPv2u. The snmptcl implementation of USEC supports authentication and privacy; however, at present the code which implements privacy, while tested with many of the other implementations listed here, is unavailable for release.

The package runs under the X Window System on UNIX and is built from Tool Command Language (Tcl7.3/Tk3.6). In addition to a MIB compiler, the package contains some minimal applications for a number of standard MIB modules.

There are two snmptcl mailing lists: one for users, and another for implementors.

Coming Soon!


ACE*COMM, a subsidiary of American Computer & Electronics Corporation, will support SNMPv2u in v2.0 of its industry-leading Win16 and Win32 WinSNMP implementations. Version 1.5 of the NetPlus® WinSNMP product line will be released on March 25, 1996, with full bi-lingual support for SNMPv1 and SNMPv2c. Version 2.0 will be released in conjunction with v2.0 of the industry-standard WinSNMP API specification, which is expected to be adopted by the WinSNMP industry working group at the end of April 1996.

In addition to the NetPlus WinSNMP Developer Kit -- where most of the SNMPv2c and SNMPv2u protocol improvements are transparent -- other ACE*COMM products that will support SNMPv1, SNMPv2c, and SNMPv2u will include the NetPlus end-user packages such as the WinSNMP Starter Kit and the WinSNMP Advanced Kit. Through ACE*COMM's provision of core WinSNMP technology to hundreds of hardware manufacturers and major software industry organizations, such as Microsoft and Oracle, these SNMPv2c and SNMPv2u implementations will see widespread deployment during the second half of 1996.

Technical questions about WinSNMP and/or ACE*COMM's WinSNMP products may be addressed to Bob Natale.

Digital POLYCENTER Manager on NetView

POLYCENTER Manager on NetView for Digital UNIX V4.1 provides client/server management of multivendor enterprise networks. You can choose the management model that best fits your environment -- centralized or distributed. There are comprehensive tools for configuration, fault and performance management, and an award winning GUI that lets you focus on managing your network not windows! Combine this with the 64-bit processing power of Alpha, and for speedy autodiscovery and the capacity to add several management applications.

As part of Digital's commitment to industry standards, the infrastructure of POLYCENTER Manager on NetView for Digital UNIX V4.1 is being enabled to support SNMPv2. Enhancements include a new API for SNMP communications that provides transparent support for the SNMPv1, SNMPv2c, and SNMPv2u (USEC) protocols. The MIB Compiler and Browser are also being enhanced to support these new protocols!

The NetView SNMP network manager is co-engineered and simultaneously released by Digital and IBM.


The PowerFlag tool is supplied by Victron B.V., a company specializing in computer peripherals such as uninterruptable power supplies (UPS). The core function of the PowerFlag tool is power protection, and it serves as an SNMP agent that implements the UPS MIB along with a small Victron-specific MIB. The software is developed by West Consulting B.V.

At N+I Vegas '96, the PowerFlag agent implementation demonstrated both SNMPv2c and SNMPv2u.

Frequently Asked Questions

Here's the USEC FAQ:

SNMP and Security

Why do we need USEC (or any security protocol for that matter) for SNMP? In particular, why can't SNMP just use the security capabilities of its underlying transport services?

Here are five good reasons:

  1. SNMP is used to monitor and control networks and network-connected equipment. If attackers can control network equipment, then they can circumvent all security mechanisms installed by a network administrator, and can re-configure all equipment as they see fit. Even being able to monitor equipment can sometimes provide sufficient information to allow an attacker to bypass the security mechanisms. So, it is vital that network control mechanisms such as SNMP are protected from use by attackers.
  2. The Transport Mappings for SNMPv2 document defines how SNMPv2 can be used over a variety of transport/internet-layer protocols. Not all of these transport/internet protocols provide security.
  3. All SNMP Security specifications (both previous standards and current drafts) state in their Constraints section that:
    ``Neither the security protocol nor its underlying security mechanisms should depend upon the ready availability of other network services (e.g., Network Time Protocol (NTP) or secret/key management protocols).''
  4. There have been barely any changes in the defined methods for using DES and MD5 as mechanisms within SNMP Security since the publication of RFC 1352 in July, 1992. The difficult parts are not the security mechansims, such as DES and MD5, but rather the administrative framework in which security operates:
  5. It is the role of the SNMPv2 administrative framework to provide these agreements. Use of authentication and privacy is meaningless in the absense of an administrative framework. 80-90% of the USEC work would still be needed even if SNMPv2 relied on the underlying security of the transport/internet-layer, e.g., as specified in RFC 1825-1829.

USEC and SNMPv2*

What are the differences between USEC and SNMPv2*?

Last summer, when USEC was introduced on the SNMPv2 WG mailing list, the SNMPv2* design team came up with four issues, which they claimed were addressed in SNMPv2:

As we have refined USEC over the last several months, we examined these concerns closely and addressed these issues and addressed those issues in an efficient and non-complex way. Let's look at these points in detail:

Standards-based Configuration

The SNMPv2* design team claimed:
``USEC deferred this

The SNMPv2* design team felt this was critical:

SNMPv2* defines such a standard MIB''

We all agree that with SNMPv2 there's no excuse any more for a device not to be configurable via SNMP. For too long, we have been living with having to set just about every configuration parameter of a router, bridge, host or terminal server from that device's local console or, at best, via a proprietary MIB, and, we should start by defining a standard MIB for SNMPv2 agents.

Note well that we have successfully used all those devices, with all of their configuration parameters, without there being a standard configuration MIB for those parameters. It should be obvious that a standard for SNMPv2's administrative framework and security protocols is quite usable, for an interim period, without there being a standard configuration MIB for their parameters.

This might be different had RFC 1447 (the Party MIB) seen widespread deployment, in which case the lack of a configuration MIB could be viewed as a step backward by customers buying products based on USEC; but this is not the case -- the Party MIB did not see widespread deployment. The only products which take an initial step backward with USEC are those from the vendors of SNMP agent stacks.

Instead, USEC believes that one of the problems with SNMPv2 was that it was too large a mouthful for the vendor community to swallow in one lump, both in defining a new standard and in implementing in one product upgrade cycle. By having a standard SNMPv2 agent configuration MIB in its second phase, USEC takes the lower-risk ``divide and conquer'' approach, and allows experience to be gained with the administrative framework and security protocols while the configuration MIB is still being defined (which was exactly the process used for OSPF, 802.1D, and the DNS, to name just three examples).

USEC is now ready to move into its second phase, and an open mailing list has been created to discuss the development of a USEC Remote Configuration MIB.

Manager/Manager and Proxy Transactions

The SNMPv2* design team claimed:
``USEC was designed with traditional manager/agent transactions in mind

The USEC architecture didn't take into account manager/manager transactions or proxies, and thus some bugs were introduced

SNMPv2* fixed those bugs''

The facts are that the pre-USEC version of SNMPv2 (specified in RFCs 1447, 1448, and 1451) had some bugs in its manager-to-manager and proxy features, and that these bugs were initially also present in USEC.

However, in the latest USEC documents, RFC 1905's concept of how the new Inform-Request PDU works is clarified, and proxies are now specified using local-proxy and remote-proxy contexts. These changes serve to incorporate manager-to-manager and proxy into the traditional manager/agent model. By achieving this, the highly-successful traditional manager/agent model is maintained to a significant extent in USEC, rather than the departure which SNMPv2* takes in defining a new, significantly different, and more complicated model.


The SNMPv2* design team claimed:
``Future USEC versions can change the whole processing model; to add machine-based naming, for example

This provides unrestricted change in the future, But the entire investment in the administrative infrastructure can be put at risk

Future SNMPv2* versions retain the processing model and allow new security protocols to be added; to add public-key authentication, for example

This protects most of the investment in software''

This is a documentation issue, as to whether certain aspects of the specification are included in the Administration Framework document or in the Security Protocols document!

By specifying some of the security concepts in the Administrative Framework document, SNMPv2* believes the SNMPv2* administrative framework will be ``saved'' from perturbation by future versions of SNMPv2. But, assuming that any such future version of SNMPv2 will be designed by technically-competent working groups, then this is unnecessary. (Of course, if a future version of SNMPv2 were to be designed by the technically-incompetent, then no document organization is sufficient to protect the infrastructure).

In contrast, USEC attempts to learn from the checkered history of SNMP Security which has undergone a number of changes, some of which were wholesale changes; that is, USEC takes the approach of putting the stable aspects of the specification in the Administrative Framework document, and the newer, more volatile security aspects in the Security Protocols document, thereby minimizing the risk of necessitating future changes to the Administrative Framework document.


The SNMPv2* design team claimed:
`` Wasn't an issue for USEC because upgrades replaced everything

In SNMPv2*, the distinction between naming and security algorithms is well modularized

This is just plain wrong. Both USEC and SNMPv2* have naming schemes, which may or may not be stable; only time will tell. In addition, USEC has no inherent requirement that a future upgrade needs to change its naming scheme; and furthermore, while USEC specifies the use of MD5 and DES as standard, it provides the capability to define a greater number of additional security algorithms (such as SHA or RC4) than SNMPv2*.

The way that SNMPv2* allows for multiple authentication and/or security protocols is by defining an Security Protocol Identifier (sPI), which travels in the clear with each SNMP message. That allows a third-party to recognize which well-known protocol (or if an enterprise-specific protocol) is in use. As such, a third-party has more information as to which data is more important, and thereby it is easier to decide what kinds of analysis to perform.

In USEC however, the authentication and privacy protocols in use are specified at the two end-points, as an attribute of the user's definition. As such, USEC messages in transit contain no information as to which security protocols are in use, which makes USEC stronger in terms of security.

Two Other Issues

There are however two other important differences between USEC and SNMPv2:

Improved Security with USEC

How has USEC security been improved?

Since the August 1995 version of USEC, the following security improvements were incorporated:

Improved Simplicity with USEC

How has USEC simplicity been improved?

Since the August 1995 version of USEC, the following simplifications were incorporated:

Please send additions, changes, and comments via electronic mail.
Last modified: Wed Jun 25 10:20:55 PDT 1997