rfc1352.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,514 行 · 第 1/5 页

   For each SnmpPrivMsg value that represents a SNMP private management
   communication, the following statements are true:

     o Its privDst component is called the privacy destination
       and identifies the SNMP party to which the
       communication is directed.

     o Its privData component is called the privacy data and
       represents the (possibly encrypted) serialization
       (according to the conventions of [12] and [1]) of a SNMP
       authenticated management communication.

5.1   Generating a Message

   This section describes the behavior of a SNMP protocol entity when it
   communicates with a SNMP party for which the privacy protocol is
   administratively specified as the Symmetric Privacy Protocol. Insofar
   as the behavior of a SNMP protocol entity when transmitting a
   protocol message is defined generically in [2], only those aspects of
   that behavior that are specific to the Symmetric Privacy Protocol are
   described below. In particular, this section describes the
   encapsulation of a SNMP authenticated management communication into a
   SNMP private management communication.

   According to [2], a SnmpPrivMsg value is constructed during Step 5 of
   generic processing. In particular, it states the privData component
   is constructed according to the privacy protocol identified for the
   SNMP party receiving the message.  When the relevant privacy protocol
   is the Symmetric Privacy Protocol, the procedure performed by a SNMP
   protocol entity whenever a management communication is to be
   transmitted by a SNMP party is as follows.

    1. If the SnmpAuthMsg value is not authenticated
       according to the conventions of the Digest
       Authentication Protocol, the generation of the private
       management communication fails according to a local
       procedure, without further processing.

    2. The local database is consulted to determine the private
       privacy key of the SNMP party receiving the message



Galvin, McCloghrie, & Davin                                    [Page 17]

RFC 1352                SNMP Security Protocols                July 1992


       (represented, for example, according to the conventions
       defined in Section 2.4.2).

    3. The SnmpAuthMsg value is serialized according to the
       conventions of [12] and [1].

    4. The octet sequence representing the serialized
       SnmpAuthMsg value is encrypted using, for example,
       the algorithm specified in Section 2.4.2 and the
       extracted private privacy key.

    5. The privData component is set to the encrypted value.

      As set forth in [2], the SnmpPrivMsg value is then serialized
      and transmitted to the receiving SNMP party.

5.2   Receiving a Message

   This section describes the behavior of a SNMP protocol entity when it
   acts as a SNMP party for which the privacy protocol is
   administratively specified as the Symmetric Privacy Protocol. Insofar
   as the behavior of a SNMP protocol entity when receiving a protocol
   message is defined generically in [2], only those aspects of that
   behavior that are specific to the Symmetric Privacy Protocol are
   described below.

   According to [2], the privData component of a received SnmpPrivMsg
   value is evaluated during Step 4 of generic processing. In
   particular, it states the privData component is evaluated according
   to the privacy protocol identified for the SNMP party receiving the
   message. When the relevant privacy protocol is the Symmetric Privacy
   Protocol, the procedure performed by a SNMP protocol entity whenever
   a management communication is received by a SNMP party is as follows.

    1. The local database is consulted to determine the private
       privacy key of the SNMP party receiving the message
       (represented, for example, according to the conventions
       defined in Section 2.4.2).

    2. The contents octets of the privData component are
       decrypted using, for example, the algorithm specified in
       Section 2.4.2 and the extracted private privacy key.

      Processing of the received message continues as specified in [2].







Galvin, McCloghrie, & Davin                                    [Page 18]

RFC 1352                SNMP Security Protocols                July 1992


6.  Clock and Secret Distribution

   The protocols described in Sections 4 and 5 assume the existence of
   loosely synchronized clocks and shared secret values. Three
   requirements constrain the strategy by which clock values and secrets
   are distributed.

     o If the value of an authentication clock is decreased, the
       last-timestamp and private authentication key must be
       changed concurrently.

       When the value of an authentication clock is decreased,
       messages that have been sent with a timestamp value
       between the value of the authentication clock and its
       new value may be replayed. Changing the private
       authentication key obviates this threat. However,
       changing the authentication clock and the private
       authentication key is not sufficient to ensure proper
       operation. If the last-timestamp is not reduced similarly
       to the authentication clock, no message will be
       considered authentic until the value of the authentication
       clock exceeds the value of the last-timestamp.

     o The private authentication key and private privacy key
       must be known only to the parties requiring knowledge
       of them.

       Protecting the secrets from disclosure is critical to the
       security of the protocols. In particular, if the secrets are
       distributed via a network, the secrets must be protected
       with a protocol that supports confidentiality, e.g., the
       Symmetric Privacy Protocol. Further, knowledge of the
       secrets must be as restricted as possible within an
       implementation. In particular, although the secrets may
       be known to one or more persons during the initial
       configuration of a device, the secrets should be changed
       immediately after configuration such that their actual
       value is known only to the software. A management
       station has the additional responsibility of recovering the
       state of all parties whenever it boots, and it may address
       this responsibility by recording the secrets on a
       long-term storage device. Access to information on this
       device must be as restricted as is practically possible.

     o There must exist at least one SNMP protocol entity that
       assumes the role of a responsible management station.

       This management station is responsible for ensuring that



Galvin, McCloghrie, & Davin                                    [Page 19]

RFC 1352                SNMP Security Protocols                July 1992


       all authentication clocks are synchronized and for
       changing the secret values when necessary. Although
       more than one management station may share this
       responsibility, their coordination is essential to the
       secure management of the network. The mechanism by
       which multiple management stations ensure that no
       more than one of them attempts to synchronize the
       clocks or update the secrets at any one time is a local
       implementation issue.

       A responsible management station may either support
       clock synchronization and secret distribution as separate
       functions, or combine them into a single functional unit.

   The first section below specifies the procedures by which a SNMP
   protocol entity is initially configured. The next two sections
   describe one strategy for distributing clock values and one for
   determining a synchronized clock value among SNMP parties supporting
   the Digest Authentication Protocol. For SNMP parties supporting the
   Symmetric Privacy Protocol, the next section describes a strategy for
   distributing secret values. The last section specifies the procedures
   by which a SNMP protocol entity recovers from a "crash."

6.1   Initial Configuration

   This section describes the initial configuration of a SNMP protocol
   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 SNMP 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 SNMP 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 SNMP parties for each SNMP
   protocol entity, one pair of which may be used initially to configure
   all other SNMP parties.



Galvin, McCloghrie, & Davin                                    [Page 20]

RFC 1352                SNMP Security Protocols                July 1992


   In fact, there is a minimal, useful set of SNMP 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:

     o a SNMP party for which the authentication protocol and
       privacy protocol are the values noAuth and noPriv,
       respectively,

     o a SNMP party for which the authentication protocol
       identifies the mechanism defined in Section 2.4.1 and its
       privacy protocol is the value noPriv, and

     o a SNMP party for which the authentication protocol and
       privacy protocol identify the mechanisms defined in
       Section 2.4.1 and Section 2.4.2, respectively.

   The last of these SNMP parties in both the responsible management
   station and the managed agent could be used to configure all other
   SNMP parties. It is the only suitable party for this purpose because
   it is the only party that supports data confidentiality, which is
   necessary in order to protect the distributed secrets from disclosure
   to unauthorized entities.

   Configuring one pair of SNMP 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.

   All 6 parties should be configured in each new managed agent and its
   responsible management station. The responsible management station
   should be configured first, since the management station 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 SNMP party to be configured. Some of these values
       may be computed by the responsible management



Galvin, McCloghrie, & Davin                                    [Page 21]

RFC 1352                SNMP Security Protocols                July 1992


       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 6.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 those secrets with a
       strategy that uses a protocol that protects them from
       disclosure, e.g., Symmetric Privacy Protocol (see
       Section 6.4). Upon receiving positive acknowledgement
       that the new values have been distributed, the
       management station should update its local database
       with the new values.