draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994
Overview of SNMPv2 Simplified Security Conventions
Mar 24, 1994
Steven Waldbusser
Carnegie Mellon University
waldbusser@cmu.edu
<draft-waldbusser-ssecov-00.txt>
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts.
Internet Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet Drafts as reference material or to cite
them other than as a "work in progress".
Waldbusser Expires Sep 24, 1994 [Page 1]
draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994
1. Introduction
This document set describes conventions that simplify the administration
and usage of SNMPv2 Security. These conventions are for use by
cooperating and consenting SNMPv2 entities and do not change or restrict
any other usage of SNMPv2 security.
This document provides an overview of these conventions, and examples of
usage at the user interface level.
Waldbusser Expires Sep 24, 1994 [Page 2]
draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994
2. The SNMPv2 Network Management Framework
The SNMPv2 Network Management Framework consists of four major
components. They are:
o RFC 1442 which defines the SMI, the mechanisms used for describing
and naming objects for the purpose of management.
o RFC 1213 defines MIB-II, the core set of managed objects for the
Internet suite of protocols.
o RFC 1445 which defines the administrative and other architectural
aspects of the framework.
o RFC 1448 which defines the protocol used for network access to
managed objects.
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
Waldbusser Expires Sep 24, 1994 [Page 3]
draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994
3. Overview
While SNMP security is an important issue on many networks today,
current operational needs dictate that security be implemented and used
in a way that doesn't harm the useability and reliability of network
management applications. This memo defines conventions for the use of
SNMP security that provide an easier to manage and easier to use system,
without changing the protocol.
The problem that network managers face with SNMP Security is the amount
of information that must be configured consistently across multiple
managers and agents before management communications may begin. This
burdens the network manager whenever:
o A new agent is installed
Each time a new agent is installed, parties must be configured and
installed on that agent, and the identical information must be
installed on every management station that may need to communicate
with that agent in the future. If a management station is left out,
it is likely that the network manager will not find out that that
station cannot communicate until a time of network (and human)
stress.
o A new management station is installed
Each time a new management station is installed, it must be loaded
with the authentication information for all agents it may ever need
to communicate with. If this management station is a new product,
the installer will probably need to translate the security
configuration database to a new format before the installation may
be completed, delaying the installation of this new product. If the
configuration for a particular agent is left out, the manager will
not be able to communicate with that agent on demand.
In addition, every agent must be updated to include authentication
information for that new management station.
o The network manager needs to "firefight" from a new location
When the network is experiencing stress and the network manager is
firefighting, the network manager may need to run management
applications from different locations on the network. This may be
in an attempt to get closer to the problem or to "set up camp" in a
portion of the network that actually works and allows the tools to
Waldbusser Expires Sep 24, 1994 [Page 4]
draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994
function. This activity is sometimes under extreme duress and time
is always a factor. A setup time of more than a few minutes is
simply unacceptable. In addition, the uncertainty associated with
relying on a complex and untested configuration can reduce the
network manager's effectiveness.
o Every time a network address changes
Every time a network address changes on a management station, all
agents must be reconfigured with the new security information for
that management station. Every time a network address changes on an
agent, all management stations must be similarly reconfigured with
new security information.
Some of these problems may be reduced with automatic configuration
programs, standard file formats and other schemes. However, these
schemes don't purport to solve all of these problems, and are neither
widely available, implemented, nor even proven tractable.
This document set describes conventions that simplify the administration
and usage of SNMPv2 Security. These conventions are for use by
cooperating and consenting SNMPv2 entities and do not change or restrict
any other usage of SNMPv2 security.
These conventions have the following advantages:
o No security administration servers are required to maintain
clocks or to administer parties and passwords.
o Many fewer parties required in the system, and even
fewer "configuration items"
o Security configuration may be performed quickly, on demand by a human
o Less NVRAM storage requirements
o With a clock-calendar chip, periodic writes to NVRAM are not required.
o No clock leapfrog problems
4. General Strategy
The Party MIB configuration for every given situation (perhaps every
particular combination of agent, management platform, and application)
either has to be memorized or be pre-configured on every system that
might need to communicate using SNMPv2 security. As a complete pre-
configuration has been difficult to implement and deploy, this memo
describes a strategy that provides a simplified configuration that can
Waldbusser Expires Sep 24, 1994 [Page 5]
draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994
be algorithmically derived, except for a minimal amount of information
that is input by a human. This human-entered information is in a format
that may be easily memorized and produced on demand, and is in a userid,
password form that network administrators are quite familiar with.
This specification introduces the concept of a userID to SNMPv2
Security. A userID names a set of security information that is used to
provide authentication and privacy functions for a user. Each userID is
represented by the configuration of two or four pairs of parties in the
SNMP Party MIB. In the absence of these conventions, quite a few
parties and other elements of security information would need to be
configured.
From the user perspective, this userid and a secret are the only things
that need to be remembered.
The next part of the strategy is that the Party MIB configuration for a
user is authoritatively defined on each agent which is being secured by
the protocol. This same configuration is used by all management
stations that may need to communicate with that agent using a particular
userID. For example, Joe Administrator will use the same security
information to reboot Router1 whether he is on NMS1 or NMS2. This will
typically be different than Jane Administrator's configuration for
Router1. In fact, each element of the party table configuration will be
named by the network address of the agent and the userid of the user.
This enables the information (such as the secret) to be different for
each agent or to be shared across agents. This allows a different
secret to be required for each system a user manages if security needs
dictate, or for a user to use the same key on many systems.
When using these conventions, a user will likely use the same
configuration from multiple management stations. In order to ensure
that no harmful interactions occur, additional rules are provided that
detail how the NMS will interact with the agent. In particular, usage
of clock values is constrained so that harmful interactions such as
clock leapfrog will not occur.
The next step in the strategy is to provide a mechanism in which the
party table configuration for a user may be algorithmically derived with
a minimum of information provided by a human. The conventions specify
that each userID will result in four parties being created on the agent.
On both the manager and the agent, the human needs to specify a userid
and a password, while the agent also requires access control information
to be specified.
Waldbusser Expires Sep 24, 1994 [Page 6]
draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994
In SNMPv2 Security, Parties and Contexts are named by OBJECT
IDENTIFIERs. Unfortunately, it is effectively impossible for humans to
remember these strings and to input them on demand. This specification
provides conventions on how those OBJECT IDENTIFIERs may be derived from
the address of the agent and other simple pieces of information.
In SNMPv2 Security, authentication keys are 16 random binary bytes.
These too are effectively impossible for a human to remember. This
specification provides a secure way that the key may be derived from an
ASCII password input by a human. This can be a single word or a phrase
of several words.
After participating systems gather a minimal amount of information from
a human and create the required party MIB configuration, communications
may begin with no further configuration necessary. These conventions
therefore allow the security configuration to be created on demand and
obviates the need for pre-configuration.
These conventions allow implementation strategies that will achieve
additional benefits. For example, an implementation may store just the
userid and password in NVRAM and translate them to Party MIB elements
upon initialization, saving NVRAM space. Implementions may choose to
delay the translation even further by performing a temporary translation
only when a particular userID is used. Administrators may choose to use
the same userid and password across several machines, and management
stations may be configured to make it quite easy to access these
similarly configured machines.
5. Examples of the public noAuth/noPriv configuration
When implemented, this configuration will work "out of the box" without
any configuration by the end user for either the management station or
the agent. It is mandatory the the agent support this configuration for
read-only access to the party clocks (at least).
Usage of this will be much like SNMPv1's use of the "public" community
string. This is arguably simpler than SNMPv1, because no parameter
needs to be given at all.
Waldbusser Expires Sep 24, 1994 [Page 7]
draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994
6. Examples of MD5 authentication configuration
6.1. Agent Initialization Examples
The agent's user interface might take many forms, depending on the
extent of configurability that the agent allows. Some examples follow.
6.1.1. Minimal Agent
A user dialog when configuring a minimal agent might look like:
========================================
ACME Bridge SNMPv2 Initialization
Please enter the password for the "admin" userid: ......
Passwords must be at least 8 characters. Please try again.
Please enter the password for the "admin" userid: ......................
========================================
In this example, the agent only provides a single userID named "admin",
and asks the installer/configurer for a password for this userID.
Waldbusser Expires Sep 24, 1994 [Page 8]
draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994
6.1.2. Normal Agent
A user dialog when configuring a normal agent might look like:
========================================
ACME Router SNMPv2 Initialization
Please enter a userid: joe
Please enter the password for joe: ......................
Please enter the view for joe. Select one of the following:
1) system and IP host configuration
2) IP routing configuration, system, and IP host configuration
3) Everything, including SNMP Security
Enter your selection: 2
Do you want to configure any more users? [y/n]: n
========================================
In this example, the agent allows a number of users to be configured and
for each to have different permissions on the agent.
Waldbusser Expires Sep 24, 1994 [Page 9]
draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994
6.1.3. Extended Agent
A user dialog when configuring an agent with extensive SNMP Security
support might look like:
========================================
ACME Chassis SNMPv2 Initialization
Please enter a userid: joe
Please enter the password for joe: ......................
Select a context, or n for new:
SubSystem Time View
1) main current default
2) repeater1 current default
Enter your selection: n
What subsystem should this user have access to:
1) repeater1
2) repeater2
Enter your selection: 2
Please enter a group to provide access to. Select one of the following:
1) system
2) repeater
3) ACME private MIB
4) RMON MIB
5) Done, no more groups
Enter your selection: 1
Please enter a group to provide access to. Select one of the following:
1) system
2) repeater
3) ACME private MIB
4) RMON MIB
5) Done, no more groups
Enter your selection: 3
Please enter a group to provide access to. Select one of the following:
1) system
2) repeater
3) ACME private MIB
4) RMON MIB
5) Done, no more groups
Enter your selection: 5
What should this view be called?: admin
Running configuration, or default? [Running/Default]: Running
Read-Write access? [y/n]: y
Added context #3. Select a context, or n for new:
SubSystem Time View
Waldbusser Expires Sep 24, 1994 [Page 10]
draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994
1) main current default
2) repeater1 current default
3) repeater2 current admin
0) Done, no more contexts
Enter your selection: 1
Added context #1. Select a context, or n for new:
SubSystem Time View
1) main current default
2) repeater1 current default
3) repeater2 current admin
0) Done, no more contexts
Enter your selection: 0
Done with joe. Do you want to configure any more users? [y/n]: n
========================================
In this example, the agent allows a number of users to be configured and
for each to have an access control list to be built up, and for
different subsystems to be controlled.
6.2. Manager Initialization
While the agent configurations can be quite simple, the manager needs
even less information to become fully configured. In the simplest case,
only a userID and a password are required.
In this example we will show the use of a command line tool, as it is
the application that is least likely to be used with a pre-configured
security database, especially when firefighting. The following example
could be followed without any prior initialization (e.g., if the snmpset
program had just been pulled off of a CDROM onto a new system).
========================================
% snmpset acme-router joe sysLocation.0 "UCC 130"
Password: ......................
sysLocation.0 = UCC 130 [Done].
% snmpset acme-chassis joe sysLocation.0 -e repeater1 "UCC 130"
Password: ......................
sysLocation.0 = UCC 130 [Done].
%
========================================
A cache of userid-key mappings may be used to avoid the frequent typing
of passwords, and to cut down on the time involved in the password to
key algorithm. Obviously this database must be kept private and must
Waldbusser Expires Sep 24, 1994 [Page 11]
draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994
only be used by authorized users.
Waldbusser Expires Sep 24, 1994 [Page 12]
draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994
7. Acknowledgements
The author wishes to thank Jeff Case, Jim Galvin, Jeff Johnson, Peter
Houck, Keith McCloghrie, John Myers, and Brian O'Keefe for their helpful
comments on the ideas in this document.
Waldbusser Expires Sep 24, 1994 [Page 13]
draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994
8. References
[1] Galvin, J., and McCloghrie, K., "Administrative Model for version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
Trusted Information Systems, Hughes LAN Systems, April, 1993
[2] Galvin, J., and McCloghrie, K., "Security Protocols for version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1446,
Trusted Information Systems, Hughes LAN Systems, April, 1993
[3] McCloghrie, K., and Galvin, J., "Party MIB for version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC 1447, Hughes LAN
Systems, Trusted Information Systems, April, 1993
Waldbusser Expires Sep 24, 1994 [Page 14]
draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994
9. Author's Address
Steven Waldbusser
Carnegie Mellon University
5000 Forbes Ave
Pittsburgh, PA 15213
US
Phone: +1 412 268 6628
Email: waldbusser@cmu.edu
Waldbusser Expires Sep 24, 1994 [Page 15]
draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994
Table of Contents
1 Introduction .................................................... 2
2 The SNMPv2 Network Management Framework ......................... 3
3 Overview ........................................................ 4
4 General Strategy ................................................ 5
5 Examples of the public noAuth/noPriv configuration .............. 7
6 Examples of MD5 authentication configuration .................... 8
6.1 Agent Initialization Examples ................................. 8
6.1.1 Minimal Agent ............................................... 8
6.1.2 Normal Agent ................................................ 9
6.1.3 Extended Agent .............................................. 10
6.2 Manager Initialization ........................................ 11
7 Acknowledgements ................................................ 13
8 References ...................................................... 14
9 Author's Address ................................................ 15
Waldbusser Expires Sep 24, 1994 [Page 16]