rfc1446.txt

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

          are specific to the Digest Authentication Protocol are
          described below.

          According to Section 3.2 of [1], a SnmpAuthMsg value is
          evaluated during Step 9 of generic processing.  In particular,
          it states the SnmpAuthMsg value is evaluated according to the
          authentication protocol identified for the SNMPv2 party that
          originated the message.  When the relevant authentication
          protocol is the Digest Authentication Protocol, the procedure
          performed by a SNMPv2 entity whenever a management
          communication is received by a SNMPv2 party is as follows.

          (1)  If the ASN.1 type of the authInfo component is not
               AuthInformation, the message is evaluated as unauthentic,
               and the snmpStatsBadAuths counter [14] is incremented.
               Otherwise, the authSrcTimestamp, authDstTimestamp, and
               authDigest components are extracted from the SnmpAuthMsg
               value.

          (2)  The local database is consulted to determine the
               authentication clock, private authentication key
               (extracted, for example, according to the conventions
               defined in Section 1.5.1), and lifetime of the SNMPv2
               party that originated the message.

          (3)  If the authSrcTimestamp component plus the lifetime is
               less than the authentication clock, the message is
               evaluated as unauthentic, and the snmpStatsNotInLifetimes
               counter [14] is incremented.

          (4)  The authDigest component is extracted and temporarily
               recorded.

          (5)  A new SnmpAuthMsg value is constructed such that its
               authDigest component is set to the private authentication
               key and its other components are set to the value of the
               corresponding components in the received SnmpAuthMsg





          Galvin & McCloghrie                                  [Page 18]





          RFC 1446        Security Protocols for SNMPv2       April 1993


               value.  This new SnmpAuthMsg value is serialized
               according to the conventions of [13] and [12].  A digest
               is computed over the octet sequence representing that
               serialized value using, for example, the algorithm
               specified in Section 1.5.1.

                                            NOTE
                    Because serialization rules are unambiguous but may
                    not be unique, great care must be taken in
                    reconstructing the serialized value prior to
                    computing the digest.  Implementations may find it
                    useful to keep a copy of the original serialized
                    value and then simply modify the octets which
                    directly correspond to the placement of the
                    authDigest component, rather than re-applying the
                    serialization algorithm to the new SnmpAuthMsg
                    value.

          (6)  If the computed digest value is not equal to the digest
               value temporarily recorded in step 4 above, the message
               is evaluated as unauthentic, and the
               snmpStatsWrongDigestValues counter [14] is incremented.

          (7)  The message is evaluated as authentic.

          (8)  The local database is consulted for access privileges
               permitted by the local access policy to the originating
               SNMPv2 party with respect to the receiving SNMPv2 party.
               If any level of access is permitted, then:

                 the authentication clock value locally recorded for the
                 originating SNMPv2 party is advanced to the
                 authSrcTimestamp value if this latter exceeds the
                 recorded value; and,

                 the authentication clock value locally recorded for the
                 receiving SNMPv2 party is advanced to the
                 authDstTimestamp value if this latter exceeds the
                 recorded value.

              (Note that this step is conceptually independent from
              Steps 15-17 of Section 3.2 in [1]).

          If the SnmpAuthMsg value is evaluated as unauthentic, an
          authentication failure is noted and the received message is





          Galvin & McCloghrie                                  [Page 19]





          RFC 1446        Security Protocols for SNMPv2       April 1993


          discarded without further processing.  Otherwise, processing
          of the received message continues as specified in [1].
















































          Galvin & McCloghrie                                  [Page 20]





          RFC 1446        Security Protocols for SNMPv2       April 1993


          4.  Symmetric Privacy Protocol

          This section describes the Symmetric Privacy Protocol.  It
          provides for protection from disclosure of a received message.
          An appropriate portion of the message is encrypted according
          to a secret key known only to the originator and recipient of
          the message.

          This protocol assumes the underlying mechanism is a symmetric
          encryption algorithm.  In addition, the message to be
          encrypted must be protected according to the conventions of
          the Digest Authentication Protocol.

          Recall from [1] that a SNMPv2 private management communication
          is represented by an ASN.1 value with the following syntax:

               SnmpPrivMsg ::= [1] IMPLICIT SEQUENCE {
                 privDst
                    OBJECT IDENTIFIER,
                 privData
                    [1] IMPLICIT OCTET STRING
               }

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

          o    Its privDst component is called the privacy destination
               and identifies the SNMPv2 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 [13] and [12]) of a
               SNMPv2 authenticated management communication.


          4.1.  Generating a Message

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





          Galvin & McCloghrie                                  [Page 21]





          RFC 1446        Security Protocols for SNMPv2       April 1993


          particular, this section describes the encapsulation of a
          SNMPv2 authenticated management communication into a SNMPv2
          private management communication.

          According to Section 3.1 of [1], 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 SNMPv2
          party receiving the message.  When the relevant privacy
          protocol is the Symmetric Privacy Protocol, the procedure
          performed by a SNMPv2 entity whenever a management
          communication is to be transmitted by a SNMPv2 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 SNMPv2 party receiving the message
               (represented, for example, according to the conventions
               defined in Section 1.5.2).

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

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

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

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


          4.2.  Receiving a Message

          This section describes the behavior of a SNMPv2 entity when it
          acts as a SNMPv2 party for which the privacy protocol is
          administratively specified as the Symmetric Privacy Protocol.
          Insofar as the behavior of a SNMPv2 entity when receiving a





          Galvin & McCloghrie                                  [Page 22]





          RFC 1446        Security Protocols for SNMPv2       April 1993


          protocol message is defined generically in [1], only those
          aspects of that behavior that are specific to the Symmetric
          Privacy Protocol are described below.

          According to Section 3.2 of [1], 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 SNMPv2 party receiving the message.  When
          the relevant privacy protocol is the Symmetric Privacy
          Protocol, the procedure performed by a SNMPv2 entity whenever
          a management communication is received by a SNMPv2 party is as
          follows.

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

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

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

























          Galvin & McCloghrie                                  [Page 23]





          RFC 1446        Security Protocols for SNMPv2       April 1993


          5.  Clock and Secret Distribution

          The protocols described in Sections 3 and 4 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
               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