blank.gif (43 bytes)

Church Of The
Swimming Elephant

Search:
5.1. Initial Configuration Connected: An Internet Encyclopedia
5.1. Initial Configuration

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1446
Up: 5. Clock and Secret Distribution
Prev: 5. Clock and Secret Distribution
Next: 5.2. Clock Distribution

5.1. Initial Configuration

5.1. Initial Configuration

This section describes the initial configuration of a SNMPv2 entity that supports the Digest Authentication Protocol or both the Digest Authentication Protocol and the Symmetric Privacy Protocol.

When a network device is first installed, its initial, secure configuration must be done manually, i.e., a person must physically visit the device and enter the initial secret values for at least its first secure SNMPv2 party. This requirement suggests that the person will have knowledge of the initial secret values.

In general, the security of a system is enhanced as the number of entities that know a secret is reduced. Requiring a person to physically visit a device every time a SNMPv2 party is configured not only exposes the secrets unnecessarily but is administratively prohibitive. In particular, when MD5 is used, the initial authentication secret is 128 bits long and when DES is used an additional 128 bits are needed - 64 bits each for the key and initialization vector. Clearly, these values will need to be recorded on a medium in order to be transported between a responsible management station and a managed agent. The recommended procedure is to configure a small set of initial SNMPv2 parties for each SNMPv2 entity, one pair of which may be used initially to configure all other SNMPv2 parties.

In fact, there is a minimal, useful set of SNMPv2 parties that could be configured between each responsible management station and managed agent. This minimal set includes one of each of the following for both the responsible management station and the managed agent:

  • a SNMPv2 party for which the authentication protocol and privacy protocol are the values noAuth and noPriv, respectively,

  • a SNMPv2 party for which the authentication protocol identifies the mechanism defined in Section 1.5.1 and its privacy protocol is the value noPriv, and

  • a SNMPv2 party for which the authentication protocol and privacy protocol identify the mechanisms defined in Section 1.5.1 and Section 1.5.2, respectively.

The last of these SNMPv2 parties in both the responsible management station and the managed agent could be used to create all other SNMPv2 parties.

Configuring one pair of SNMPv2 parties to be used to configure all other parties has the advantage of exposing only one pair of secrets - the secrets used to configure the minimal, useful set identified above. To limit this exposure, the responsible management station should change these values as its first operation upon completion of the initial configuration. In this way, secrets are known only to the peers requiring knowledge of them in order to communicate.

The Management Information Base (MIB) document [4] supporting these security protocols specifies 6 initial party identities and initial values, which, by convention, are assigned to the parties and their associated parameters.

These 6 initial parties are required to exist as part of the configuration of implementations when first installed, with the exception that implementations not providing support for a privacy protocol only need the 4 initial parties for which the privacy protocol is noPriv. When installing a managed agent, these parties need to be configured with their initial secrets, etc., both in the responsible management station and in the new agent.

If the responsible management station is configured first, it can be used to generate the initial secrets and provide them to a person, on a suitable medium, for distribution to the managed agent. The following sequence of steps describes the initial configuration of a managed agent and its responsible management station.

  1. Determine the initial values for each of the attributes of the SNMPv2 party to be configured. Some of these values may be computed by the responsible management station, some may be specified in the MIB document, and some may be administratively determined.

  2. Configure the parties in the responsible management station, according to the set of initial values. If the management station is computing some initial values to be entered into the agent, an appropriate medium must be present to record the values.

  3. Configure the parties in the managed agent, according to the set of initial values.

  4. The responsible management station must synchronize the authentication clock values for each party it shares with each managed agent. Section 5.3 specifies one strategy by which this could be accomplished.

  5. The responsible management station should change the secret values manually configured to ensure the actual values are known only to the peers requiring knowledge of them in order to communicate. To do this, the management station generates new secrets for each party to be reconfigured and distributes the updates using any strategy which protects the new values from disclosure; use of a SNMPv2 set operation acting on the managed objects defined in [4] is such a strategy. Upon receiving positive acknowledgement that the new values have been distributed, the management station should update its local database with the new values.

If the managed agent does not support a protocol that protects messages from disclosure, e.g., the Symmetric Privacy Protocol (see section 5.4), then the distribution of new secrets, after the compromise of existing secrets, is not possible. In this case, the new secrets can only be distributed by a physical visit to the device.

If there are other SNMPv2 protocol entities requiring knowledge of the secrets, the responsible management station must distribute the information upon completion of the initial configuration. The considerations, mentioned above, concerning the protection of secrets from disclosure, also apply in this case.


Next: 5.2. Clock Distribution

Connected: An Internet Encyclopedia
5.1. Initial Configuration

Cotse.Net

Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!

Service Details

 
.
www.cotse.com
Have you gone to church today?
.
All pages ©1999, 2000, 2001, 2002, 2003 Church of the Swimming Elephant unless otherwise stated
Church of the Swimming Elephant©1999, 2000, 2001, 2002, 2003 Cotse.com.
Cotse.com is a wholly owned subsidiary of Packetderm, LLC.

Packetderm, LLC
210 Park Ave #308
Worcester, MA 01609