USEC: A User-based Security Model for SNMPv2

Introduction

Computer networking professionals have been seeking a solution to the problem of secure network management for some time. The concern that all MIS professionals share is that some unscrupulous intruder will be able to use Simple Network Management Protocol (SNMP) calls to shut down a bridge, rearrange a routing table, or generally disrupt their computer network.

Originally, SNMP version 2, the next generation of SNMP developed by the Internet Engineering Task Force (IETF) was supposed to address this issue by incorporating network security within the standard. However, efforts over the last three years to add security to SNMPv2 have stalled. Various security models have been proposed, but the computer networking industry in general and the IETF in particular have yet to reach a consensus and embrace a single approach to SNMP security.

Although various solutions have been proposed to address this problem, the first to be demonstrated is the User-based Security Model or USEC. The architects of USEC hope that, by demonstrating to the industry how easy this technology is to implement and deploy, the IETF will elect to incorporate USEC as a standardized security extension to SNMPv2.

This white paper is designed to outline some of the issues surrounding SNMP security, provide a brief history of SNMPv2 and the security issues associated with it, and to explain the architecture and advantages of USEC.

The History of SNMPv2

The Simple Network Management Protocol (SNMP) has been evolving since it was first developed by the Internet Engineering Task Force (IETF) nearly a decade ago. The functionality of the original SNMP technology, SNMP version 1, could always be extended using Management Information Base modules (MIBs) that define specific monitoring and control functions, but MIS professionals and computer networking engineers found that they wanted more functionality than could be offered through MIB extensions alone. In addition, there was a desire to add network management security to the SNMP standard. Therefore the IETF formed two working groups, the SNMPv2 working group and the SNMP Security working group, to create a new SNMP standard with more functionality and greater security.

In reality, SNMPv2 is not a new standard but is actually an extension to SNMPv1 designed to add functionality and security. There are a number of specific advantages that have emerged from the SNMPv2 standardization effort:

The oral tradition behind the original SNMP effort is now fully documented. The importance of this historical effort cannot be underestimated since it provides the basis for cohesive, well-thought-out changes to the existing SNMP standard as network management continues to evolve.
Useful extensions have been made to the existing language for defining managed objects. This makes it easier to write, understand, and implement managed devices.
Performance and other improvements have also been made to the SNMP protocol to make the exchange of management objects cleaner and more efficient.

All of these changes were in keeping with the original design of SNMP. There are some basic tenets behind the SNMP design philosophy that need to be honored to assure consistency and future compatibility:

Any changes to the existing SNMP standard must have a minimal impact on managed nodes, since these nodes vary widely in the resources they can devote to management.
If network management is to be considered an essential part of computer networking, then it needs to be deployed in the largest possible number of devices throughout the network, i.e. it must be easy to deploy.
When all else fails, network management must continue to function if at all possible, which means the standard must be sufficiently well-defined to make an SNMP application robust.

To develop efficient, real-world SNMP applications, the SNMP designer needs to follow some basic principles:

make minimal use of abstractions and choices;
make minimal requirements of the transport service, the communications stack, and the agent resources; and,
have a minimal impact on the managed nodes.

By following these tenets, the cost of entry for SNMP management can be minimized and more network devices can be deployed with SNMP agents, thereby maximizing the rate of adoption for SNMP support in real-world networks.

The current SNMPv2 standard (without the security infrastructure) meets all of these criteria. However, as the security issues became clearly defined in the original SNMPv2 specification, the cost of entry began to escalate rapidly, largely because of the overhead from SNMPv2's administrative framework and remote configuration features. In fact, the additional burden caused by security made it impossible for all but a few technology providers to develop correct SNMPv2 implementations, and even fewer users could deploy them in the field.

The Challenge of SNMP Security

The core problem behind the original SNMPv2's administrative and remote configuration features was the notion of a ``party.'' In SNMPv2 terms, a party defines:

transport, which specifies where in the network the management entity resides, along with information about the maximum size of the message it is able to receive;
clocks, which detect duplication or retransmission (replay) of messages;
keys, which are used to authenticate and encrypt SNMP messages; and,
access rights, which specify those operations and objects that are permitted to other SNMP entities.

The problem with this concept of parties defined within SNMPv2 is that they are tightly integrated with every aspect of the SNMP entity, resulting in an ``all-or-nothing'' approach to network management; in order to gain even the simplest SNMP functionality, an SNMPv2 application had to support the entire party infrastructure! A second problem was that configuration in the field had to accommodate all four areas; a task which proved to be unscalable and ultimately impractical.

To address the problem posed by parties, a number of alternatives were considered. A Simplified Security scheme that added a ``user'' concept on top of the SNMPv2 parties was examined. This scheme would recognize user identities as consistent throughout an SNMP infrastructure, which would minimize the configuration burden; i.e. mapping from users to parties would be performed only once when the agent was initially configured. This approach had the benefit of retaining the party structure while reducing the level of configuration complexity to a more manageable linear cost. The SNMPv2 working group ultimately rejected the user concept because it required different entities to share the same parties in an uncoordinated fashion. Variations on the user scheme were also considered and rejected as too complex and burdensome to be practical.

Then, early in 1995, Glenn Waters of Bell-Northern Research came forward with a revelation that formed the basis for USEC. Enter the User-based Security Model for SNMPv2: Waters observed that it would be relatively simple to create a secure SNMP environment using the following approach:

Eliminate the party-based definitions;
Retain the user-based configuration and its linear complexity;
Retain the four core security elements; and,
Dramatically reduce the complexity of the architecture and its implementation.

The resulting security scheme would be extremely small in cost and overhead, and would provide core competence and a strong security infrastructure for SNMP. In addition, focusing on user-based identification would mean SNMP agent configuration would be easy and intuitive.

Waters' approach was then embraced by Keith McCloghrie and Marshall T. Rose, two of the original SNMP authors, and evolved into the User-based Security Model (USEC) extension to SNMPv2.

Within the USEC model are three distinct concepts:

transport and clock information are agent-specific;
key information is user-specific; and,
access rights are formed from the intersection of the transport/clock and key information.

Using this security model, USEC provides a lightweight, easy-to-deploy, and agent-friendly security scheme that supports three aspects of user authentication: replay protection, message integrity, and origin identity. Replay protection prevents an intruder from capturing an SNMP packet for use at a later time, such as a command to reboot a router. Message integrity ensures that the content of a packet cannot be changed without detection, e.g. changing a command to dump the routing tables to a command to modify the routing tables. Origin identity ensures that the identity of the originator of an SNMP operation is who he or she appears to be. USEC also provides privacy as an option.

The result is a robust security scheme that is completely compatible and interoperable with the current SNMP standard, that has a minimum impact on the SNMP agent, and that is easy to implement, provision, and deploy.

Honoring the Philosophy Behind SNMP

Other approaches to SNMP security have also been put forward that are striving to create a ``complete and correct'' SNMP security structure, most notably SNMPv2*. Unfortunately, the SNMPv2* proposal is extremely complex, which means it will be difficult to deploy in a practical fashion in a production network. The SNMPv2* proposal focuses on the network management station, adding a significant amount of infrastructure to give the management station a variety of approaches to implement security. The result is that a significant burden is placed on the SNMP agent, and the network manager who needs to deploy and provision those agents in a working SNMP-supported network.

Essentially, SNMPv2* postulates that more security options make for better SNMP security. But as you extend a growing number of security schemes, how can you be sure that the SNMP security options supported by your network management station will be the same as those deployed in SNMP agents throughout the network? The result is that the Simple Network Management Protocol infrastructure is now far from simple to support.

The USEC approach represents a return to the core competencies of the original SNMP. USEC is designed to implement SNMP security using small, efficient implementations. There is consensus in the computer networking community on how to approach user authentication using passwords to cryptographic keying, and this same authentication scheme is supported by USEC.

The one philosophy that has served as the guiding light of all SNMP thought has been that whenever you have to choose in favor of placing the management burden on the network management station or the SNMP agent, the rule is to minimize the burden on the agent. The USEC approach to SNMP security whole-heartedly embraces this philosophy.

Finally, in some ways the arguments over the best approach to SNMP security detract from the core issue. The arguments should not be about security but about how to best structure the administrative framework in which security operates. How you choose to manage applications, to identify collections of managed objects, to track operators and users - the entire SNMP naming infrastructure - is the central issue. Once you agree on an administrative framework, then deploying an authentication algorithm and privacy algorithm becomes a relatively trivial task.

A USEC Technology Demonstration

USEC was first proposed in May 1995 and has been in development ever since. USEC is currently being tested by a number of network management professionals and has been demonstrated to be fully interoperable with the current release of SNMPv2, SNMPv2c, approved by the IETF at its December 1995 meeting.

At ComNet in Washington D.C. this month, USEC will be demonstrated for the first time working with SNMPv2. The USEC demonstration will be jointly conducted by Marshall T. Rose (one of SNMP's original authors), Epilogue Technology Corporation, and IBM. This demonstration will show how USEC can extend SNMPv2 through an upgraded administrative infrastructure that incorporates security.

Four independently developed USEC implementations will be shown to interoperate. IBM will demonstrate USEC support they have added to a NetView network management station running in their booth, which will interoperate with USEC-compliant SNMP agents from both Epilogue Technology and Glenn Waters (the original USEC author) running in the Epilogue booth. In addition, USEC-compliant management applications written using the openly available SNMPTcl package will be running in the Epilogue booth and will also interoperate with agents in both the Epilogue and IBM booths. (SNMPTcl was written by Marshall T. Rose of Dover Beach Consulting and Keith McCloghrie of Cisco Systems, two of the original authors of SNMP and SNMPv2).

The purpose of the demonstration is to show the industry at large that USEC provides real SNMP security, and that it is ready to deploy to complement SNMPv2 today. The demonstration will also show how easy the USEC security scheme is to deploy and support in a working computer network.

For more information, contact:

Marshall T. Rose
Dover Beach Consulting, Inc.
(415) 968-1052

David Preston
Epilogue Technology Corporation
(505) 271-9933

Tom Woolf
Woolf Media Relations, Inc.
(415) 508-1554

Tom Woolf, Woolf Media Relations, Inc.

Last modified: Sat Mar 30 13:20:04 PST 1996