rfc1352.txt

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

   If the managed agent does not support a protocol that protects
   messages from disclosure, then automatic maintenance and
   configuration of parties is not possible, i.e., the last step above
   is not possible. The secrets can only be changed by a physical visit
   to the device.

   If there are other SNMP protocol entities requiring knowledge of the
   secrets, the responsible management station must distribute the
   information upon completion of the initial configuration. The
   mechanism used must protect the secrets from disclosure to
   unauthorized entities. The Symmetric Privacy Protocol, for example,
   is an acceptable mechanism.

6.2   Clock Distribution

   A responsible management station must ensure that the authentication
   clock value for each SNMP party for which it is responsible




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


     o is loosely synchronized among all the local databases in
       which it appears,

     o is reset, as indicated below, upon reaching its maximal
       value, and

     o is non-decreasing, except as indicated below.

   The skew among the clock values must be accounted for in the lifetime
   value, in addition to the expected communication delivery delay.

   A skewed authentication clock may be detected by a number of
   strategies, including knowledge of the accuracy of the system clock,
   unauthenticated queries of the party database, and recognition of
   authentication failures originated by the party.

   Whenever clock skew is detected, and whenever the SNMP entities at
   both the responsible management station and the relevant managed
   agent support an appropriate privacy protocol (e.g., the Symmetric
   Privacy Protocol), a straightforward strategy for the correction of
   clock skew is simultaneous alteration of authentication clock and
   private key for the relevant SNMP party. If the request to alter the
   key and clock for a particular party originates from that same party,
   then, prior to transmitting that request, the local notion of the
   authentication clock is artificially advanced to assure acceptance of
   the request as authentic.

   More generally, however, since an authentication clock value need not
   be protected from disclosure, it is not necessary that a managed
   agent support a privacy protocol in order for a responsible
   management station to correct skewed clock values. The procedure for
   correcting clock skew in the general case is presented in Section
   6.3.

   In addition to correcting skewed notions of authentication clocks,
   every SNMP entity must react correctly as an authentication clock
   approaches its maximal value. If the authentication clock for a
   particular SNMP party ever reaches the maximal time value, the clock
   must halt at that value.  (The value of interest may be the maximum
   less lifetime.  When authenticating a message, its authentication
   timestamp is added to lifetime and compared to the authentication
   clock.  A SNMP protocol entity must guarantee that the sum is never
   greater than the maximal time value.) In this state, the only
   authenticated request a management station should generate for this
   party is one that alters the value of at least its authentication
   clock and private authentication key. In order to reset these values,
   the responsible management station may set the authentication
   timestamp in the message to the maximal time value. In this case, the



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


   nonce value may be used to distinguish multiple messages.

   The value of the authentication clock for a particular SNMP party
   must never be altered such that its new value is less than its old
   value, unless its last-timestamp and private authentication key are
   also altered at the same time.

6.3   Clock Synchronization

   Unless the secrets are changed at the same time, the correct way to
   synchronize clocks is to advance the slower clock to be equal to the
   faster clock. Suppose that party agentParty is realized by the SNMP
   entity in a managed agent; suppose that party mgrParty is realized by
   the SNMP entity in the corresponding responsible management station.
   For any pair of parties, there are four possible conditions of the
   authentication clocks that could require correction:

    1. The management station's notion of the value of the
       authentication clock for agentParty exceeds the agent's
       notion.

    2. The management station's notion of the value of the
       authentication clock for mgrParty exceeds the agent's
       notion.

    3. The agent's notion of the value of the authentication
       clock for agentParty exceeds the management station's
       notion.

    4. The agent's notion of the value of the authentication
       clock for mgrParty exceeds the management station's
       notion.

   The selective clock acceleration mechanism intrinsic to the protocol
   corrects conditions 2 and 3 as part of the normal processing of an
   authentic message. Therefore, the clock adjustment procedure below
   does not provide for any adjustments in those cases. Rather, the
   following sequence of steps specifies how the clocks may be
   synchronized when condition 1, condition 4, or both of those
   conditions are manifest.

    1. The responsible management station saves its existing
       notions of the authentication clocks for the two parties
       agentParty and mgrParty.

    2. The responsible management station retrieves the
       authentication clock values for both agentParty and
       mgrParty from the agent. This retrieval must be an



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


       unauthenticated request, since the management station
       does not know if the clocks are synchronized. If the
       request fails, the clocks cannot be synchronized, and the
       clock adjustment procedure is aborted without further
       processing.

    3. If the management station's notion of the authentication
       clock for agentParty exceeds the notion just retrieved
       from the agent by more than the amount of the
       communications delay between the two protocol entities,
       then condition 1 is manifest. The recommended estimate
       of communication delay in this context is one half of the
       lifetime value recorded for agentParty.

    4. If the notion of the authentication clock for mgrParty
       just retrieved from the agent exceeds the management
       station's notion, then condition 4 is manifest, and the
       responsible management station advances its notion of
       the authentication clock for mgrParty to match the
       agent's notion.

    5. If condition 1 is manifest, then the responsible
       management station sends an authenticated
       management operation to the agent that advances the
       agent's notion of the authentication clock for
       agentParty to be equal to the management station's
       notion. If this management operation fails, then the
       management station restores its previously saved notions
       of the clock values, and the clock adjustment procedure
       is aborted without further processing.

    6. The responsible management station retrieves the
       authentication clock values for both agentParty and
       mgrParty from the agent. This retrieval must be an
       authenticated request, in order that the management
       station may verify that the clock values are properly
       synchronized. If this authenticated query fails, then the
       management station restores its previously saved notions
       of the clock values, and the clock adjustment procedure
       is aborted without further processing. Otherwise, clock
       synchronization has been successfully realized.

   It is important to note step 4 above must be completed before
   attempting step 5. Otherwise, the agent may evaluate the request in
   step 5 as unauthentic. Similarly, step 5 above must be completed
   before attempting step 6. Otherwise, the management station may
   evaluate the query response in step 6 as unauthentic.




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


   Administrative advancement of a clock as described above does not
   introduce any new vulnerabilities, since the value of the clock is
   intended to increase with the passage of time. A potential
   operational problem is the rejection of management operations that
   are authenticated using a previous value of the relevant party clock.
   This possibility may be avoided if a management station suppresses
   generation of management traffic between relevant parties while this
   clock adjustment procedure is in progress.

6.4   Secret Distribution

   This section describes one strategy by which a SNMP protocol entity
   that supports both the Digest Authentication Protocol and the
   Symmetric Privacy Protocol can change the secrets for a particular
   SNMP party.

   The frequency with which the secrets of a SNMP party should be
   changed is a local administrative issue. However, the more frequently
   a secret is used, the more frequently it should be changed. At a
   minimum, the secrets must be changed whenever the associated
   authentication clock approaches its maximal value (see Section 7).
   Note that, owing to both administrative and automatic advances of the
   authentication clock described in this memo, the authentication clock
   for a SNMP party may well approach its maximal value sooner than
   might otherwise be expected.

   The following sequence of steps specifies how a responsible
   management station alters a secret value (i.e., the private
   authentication key or the private privacy key) for a particular SNMP
   party.

    1. The responsible management station generates a new
       secret value.

    2. The responsible management station encapsulates a
       SNMP Set request in a SNMP private management
       communication with at least the following properties.

        o Its source supports the Digest Authentication
          Protocol and the Symmetric Privacy Protocol.

        o Its destination supports the Symmetric Privacy
          Protocol and the Digest Authentication Protocol.

    3. The SNMP private management communication is
       transmitted to its destination.

    4. Upon receiving the request, the recipient processes the



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


       message according to [1] and [2].

    5. The recipient encapsulates a SNMP Set response in a
       SNMP private management communication with at least
       the following properties.

        o Its source supports the Digest Authentication
          Protocol and the Symmetric Privacy Protocol.

        o Its destination supports the Symmetric Privacy
          Protocol and the Digest Authentication Protocol.

    6. The SNMP private management communication is
       transmitted to its destination.

    7. Upon receiving the response, the responsible
       management station updates its local database with the
       new value.

   If the responsible management station does not receive a response to
   its request, there are two possible causes.

     o The request may not have been delivered to the
       destination.

     o The response may not have been delivered to the
       originator of the request.

   In order to distinguish the two possible error conditions, a
   responsible management station could check the destination to see if
   the change has occurred. Unfortunately, since the secret values are
   unreadable, this is not directly possible.

   The recommended strategy for verifying key changes is to set the
   public value corresponding to the secret being changed to a
   recognizable, novel value: that is, alter the public authentication
   key value for the relevant party when changing its private
   authentication key, or alter its public privacy key value when
   changing its private privacy key. In this way, the responsible
   management station may retrieve the public value when a response is
   not received, and verify whether or not the change has taken place.
   (This strategy is available since the public values are not used by
   the protocols defined in this memo. If this strategy is employed,
   then the public values are significant in this context. Of course,
   protocols using the public values may make use of this strategy
   directly.)

   One other scenario worthy of mention is using a SNMP party to change



Galvin, McCloghrie, & Davin