rfc1446.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,792 行 · 第 1/5 页

               value may be replayed.  Changing the private
               authentication key obviates this threat.

          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.  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 SNMPv2 entity that assumes
               the role of a responsible management station.

               This management station is responsible for ensuring that
               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





          Galvin & McCloghrie                                  [Page 24]





          RFC 1446        Security Protocols for SNMPv2       April 1993


               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
          SNMPv2 entity is initially configured.  The next two sections
          describe one strategy for distributing clock values and one
          for determining a synchronized clock value among SNMPv2
          parties supporting the Digest Authentication Protocol.  For
          SNMPv2 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
          SNMPv2 entity recovers from a "crash."


          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.





          Galvin & McCloghrie                                  [Page 25]





          RFC 1446        Security Protocols for SNMPv2       April 1993


          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:

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

          o    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

          o    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.






          Galvin & McCloghrie                                  [Page 26]





          RFC 1446        Security Protocols for SNMPv2       April 1993


          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





          Galvin & McCloghrie                                  [Page 27]





          RFC 1446        Security Protocols for SNMPv2       April 1993


          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.


          5.2.  Clock Distribution

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

          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 SNMPv2
          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 SNMPv2 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.





          Galvin & McCloghrie                                  [Page 28]





          RFC 1446        Security Protocols for SNMPv2       April 1993


          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 5.3.

          In addition to correcting skewed notions of authentication
          clocks, every SNMPv2 entity must react correctly as an
          authentication clock approaches its maximal value.  If the
          authentication clock for a particular SNMPv2 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 SNMPv2 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.

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


          5.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 SNMPv2 entity in a managed agent; suppose that
          party mgrParty is realized by the SNMPv2 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.






          Galvin & McCloghrie                                  [Page 29]





          RFC 1446        Security Protocols for SNMPv2       April 1993


          (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 1, 2 and 3 as part of the normal
          p