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:

• The USEC errata list has been updated.

This page describes:

• The current status of USEC
  • Specifications
  • At the 35th meeting of the IETF
  • What's Next
• Implementations of USEC
  • Commercial Implementations
    • Epilogue Technology
    • IBM SystemView for AIX
  • Openly-Available Implementations
    • CMU SNMP
    • NetSCARF
    • Scotty
    • snmptcl
  • Coming Soon!
    • ACE*COMM WinSNMP
    • Digital POLYCENTER Manager on NetView
    • PowerFlag
• Recent Events
  • USEC BOF at N+I Vegas '96
  • USEC Demonstration at ComNet '96
• Frequently Asked Questions
  • SNMP and Security
  • USEC and SNMPv2*
  • Improved Security with USEC
  • Improved Simplicity with USEC

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.

Status

Specifications

• An Administrative Infrastructure for SNMPv2; and,
• The User-based Security Model for SNMPv2.

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:

• SMI for SNMPv2;
• Textual Conventions for SNMPv2;
• Conformance Statements for SNMPv2;
• Protocol Operations for SNMPv2;
• Transport Mappings for SNMPv2;
• MIB for SNMPv2; and,
• Coexistence between SNMPv1 and SNMPv2.

At the 35th meeting of the IETF

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

Recent Events

USEC BOF at N+I Vegas '96

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

USEC Demonstration at ComNet '96

Implementations

Commercial Implementations

Epilogue Technology

• Envoy, Epilogue's flagship technology, a compact, fast, portable SNMP solution that allows OEMs and system integrators to readily incorporate Simple Network Management Protocol support into their own products;
• Emissary, an SNMP MIB compiler that allows SNMP implementors to extend standard SNMP variables to support extensions to the MIBs in each managed device; and,
• Ambassador, a complete, portable implementation of the RMON remote monitoring agent.

IBM SystemView for AIX

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

CMU SNMP

• an agent that support both SNMPv1 and SNMPv2u; and,
• a number command line based applications that support both SNMPv1 and SNMPv2u.

NetSCARF

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

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

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 WinSNMP

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

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.

PowerFlag

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

Frequently Asked Questions

SNMP and Security

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:
   • in order to use authentication, there has to be agreement on what ``things'' are authenticated in agents and managers; i.e., how do you identify network management entities.
   • in order to have access control, there has to be agreement on how managed objects are identified, particularly since agents often support managed objects within multiple contexts each of which can have multiple MIB views.
   • in order to extend manager-agent interactions to support those agents which proxy for other agents, there has to be agreement on how proxy fits into the authentication and access control framework.
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*

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:

• SNMPv2* has a standards-based configuration MIB, USEC does not;
• USEC doesn't accommodate manager/manager or proxy transactions;
• SNMPv2* is more extensible; and,
• SNMPv2* is more modular.

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

``USEC deferred this

The SNMPv2* design team felt this was critical:

• Without it, security would suffer as passwords couldn't be conveniently changed and old employee's accounts couldn't be deleted
  • Except at the console of the (often remote) agent
• Proprietary MIBs would fragment the market

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

``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.

Extensibility

``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.

Modularity

`` Wasn't an issue for USEC because upgrades replaced everything

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

• Naming is stable
• Security algorithms may be easily added''

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

• SNMPv2* allows each user to have multiple security algorithms; USEC believes such capability is unlikely to be needed, that the extra complexity to allow it is unwarranted, and that a network operator can get equivalent functionality by using multiple user names, one for each security algorithm.
• SNMPv2* uses a single global-name for each context which is supported by proxy, no matter how many proxy agents are in the path between manager and agent. In contrast, USEC names such a context with a different ``alias'' name for each hop through a proxy agent. This allows the name of contexts to be locally-administered, rather than globally administered; for example, multiple adjoining administrations can choose different names for the same context, with each name being more meaningful for the local administration.

Improved Security with USEC

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

• USEC uses Keyed-MD5 for authentication. This means that the 128-bit secret key is not only inserted in the message, but also appended to it before the MD5 digest is calculated. This gives a much stronger digest.
• USEC uses localized keys to access each agent. An agent only stores the localizedKey, and so when an agent is compromised, other agents are not also compromised as a result. This is particularly important when a user uses one password to access many agents.
  A key is generated from a user's password by logically concatenating the user's password to itself as many times as needed to fill a 1MB buffer. Then a MD5 digest is calculated over this buffer, producing an intermediateKey. Authenticated communication with an agent (uniquely identified by a 12-byte agentID) is done by localizing intermediateKey for each agent. The agentID is concatenated to the intermediateKey and then the intermediateKey is appended to that. Over this new 44 octet buffer, a MD5 digest is calculated to produce a localizedKey, which is then used as the key for the authPrivateKey and/or the privPrivateKey when calculating the Keyed-MD5 digest of a message or encrypting a PDU value. For more information, see Optimizing Key Distribution by Uri Blumenthal, N.C. Hien and Bert Wijnen in the January, 1996 issue of The Simple Times.
• The use of localized keys increases the difficulty of traffic analysis attacks; and, even if a key is learned it usefulness is limited to a single agent.
• An SNMPv2 USEC message does not carry any indication as to which authentication or privacy protocol is being used. The definition of the protocols in use is at both end-points as attributes of a userName. So an attacker has no clue as to which protocol he/she should try to analyze and/or break (specifically if one decides to use different protocols than the ones defined in RFC 1910).

Improved Simplicity with USEC

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

• So-called maintenance operations, that were inherited from the Party Model, are no longer part of the USEC model. Discovery and unauthenticated access is possible via the mandatory userName ``public''.
• A report is always generated with the same userName as the message that caused the report. To provide for authentic clock synchronization, a notInWindows report is authenticated if the message that causedthe report was authenticated.
• Time synchronization always happens automatically (via an authenticated notInWindows report) and so there is no mandatory requirement that an SNMPv2 entity in a manager role a priori performs a time synchronization step.
• A ``reportableFlag'' has been added to the quality-of-service parameter so that an agent can more easily decide if a report needs to be returned in case of problems.
• Since SNMPv2c is now a separate RFC document, need for accommodating the SNMPv2c model within USEC.