rfc1446.txt

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

          (3)  The protocol should provide that the apparent time of
               generation for each received SNMPv2 message is recent.

          (4)  The protocol should provide, when necessary, that the
               contents of each received SNMPv2 message are protected
               from disclosure.

          In addition to the principal goal of supporting secure network
          management, the design of any SNMPv2 security protocol is also
          influenced by the following constraints:

          (1)  When the requirements of effective management in times of
               network stress are inconsistent with those of security,
               the former are preferred.

          (2)  Neither the security protocol nor its underlying security
               mechanisms should depend upon the ready availability of
               other network services (e.g., Network Time Protocol (NTP)
               or secret/key management protocols).

          (3)  A security mechanism should entail no changes to the
               basic SNMP network management philosophy.


          1.4.  Security Services

          The security services necessary to support the goals of a
          SNMPv2 security protocol are as follows.

          Data Integrity
               is the provision of the property that data has not been
               altered or destroyed in an unauthorized manner, nor have
               data sequences been altered to an extent greater than can
               occur non-maliciously.

          Data Origin Authentication
               is the provision of the property that the claimed origin
               of received data is corroborated.

          Data Confidentiality
               is the provision of the property that information is not
               made available or disclosed to unauthorized individuals,
               entities, or processes.







          Galvin & McCloghrie                                   [Page 6]





          RFC 1446        Security Protocols for SNMPv2       April 1993


          The protocols specified in this memo require both data
          integrity and data origin authentication to be used at all
          times.  For these protocols, it is not possible to realize
          data integrity without data origin authentication, nor is it
          possible to realize data origin authentication without data
          integrity.

          Further, there is no provision for data confidentiality
          without both data integrity and data origin authentication.


          1.5.  Mechanisms

          The security protocols defined in this memo employ several
          types of mechanisms in order to realize the goals and security
          services described above:

          o    In support of data integrity, a message digest algorithm
               is required.  A digest is calculated over an appropriate
               portion of a SNMPv2 message and included as part of the
               message sent to the recipient.

          o    In support of data origin authentication and data
               integrity, the portion of a SNMPv2 message that is
               digested is first prefixed with a secret value shared by
               the originator of that message and its intended
               recipient.

          o    To protect against the threat of message delay or replay,
               (to an extent greater than can occur through normal
               operation), a timestamp value is included in each message
               generated.  A recipient evaluates the timestamp to
               determine if the message is recent.  This protection
               against the threat of message delay or replay does not
               imply nor provide any protection against unauthorized
               deletion or suppression of messages.  Other mechanisms
               defined independently of the security protocol can also
               be used to detect message replay (e.g., the request-id
               [2]), or for set operations, the re-ordering, replay,
               deletion, or suppression of messages (e.g., the MIB
               variable snmpSetSerialNo [14]).

          o    In support of data confidentiality, a symmetric
               encryption algorithm is required.  An appropriate portion
               of the message is encrypted prior to being transmitted to





          Galvin & McCloghrie                                   [Page 7]





          RFC 1446        Security Protocols for SNMPv2       April 1993


               its recipient.

          The security protocols in this memo are defined independently
          of the particular choice of a message digest and encryption
          algorithm - owing principally to the lack of a suitable metric
          by which to evaluate the security of particular algorithm
          choices.  However, in the interests of completeness and in
          order to guarantee interoperability, Sections 1.5.1 and 1.5.2
          specify particular choices, which are considered acceptably
          secure as of this writing.  In the future, this memo may be
          updated by the publication of a memo specifying substitute or
          alternate choices of algorithms, i.e., a replacement for or
          addition to the sections below.


          1.5.1.  Message Digest Algorithm

          In support of data integrity, the use of the MD5 [3] message
          digest algorithm is chosen.  A 128-bit digest is calculated
          over the designated portion of a SNMPv2 message and included
          as part of the message sent to the recipient.

          An appendix of [3] contains a C Programming Language
          implementation of the algorithm.  This code was written with
          portability being the principal objective.  Implementors may
          wish to optimize the implementation with respect to the
          characteristics of their hardware and software platforms.

          The use of this algorithm in conjunction with the Digest
          Authentication Protocol (see Section 3) is identified by the
          ASN.1 object identifier value v2md5AuthProtocol, defined in
          [4].  (Note that this protocol is a modified version of the
          md5AuthProtocol protocol defined in RFC 1352.)

          For any SNMPv2 party for which the authentication protocol is
          v2md5AuthProtocol, the size of its private authentication key
          is 16 octets.

          Within an authenticated management communication generated by
          such a party, the size of the authDigest component of that
          communication (see Section 3) is 16 octets.









          Galvin & McCloghrie                                   [Page 8]





          RFC 1446        Security Protocols for SNMPv2       April 1993


          1.5.2.  Symmetric Encryption Algorithm

          In support of data confidentiality, the use of the Data
          Encryption Standard (DES) in the Cipher Block Chaining mode of
          operation is chosen.  The designated portion of a SNMPv2
          message is encrypted and included as part of the message sent
          to the recipient.

          Two organizations have published specifications defining the
          DES: the National Institute of Standards and Technology (NIST)
          [5] and the American National Standards Institute [6].  There
          is a companion Modes of Operation specification for each
          definition (see [7] and [8], respectively).

          The NIST has published three additional documents that
          implementors may find useful.

          o    There is a document with guidelines for implementing and
               using the DES, including functional specifications for
               the DES and its modes of operation [9].

          o    There is a specification of a validation test suite for
               the DES [10].  The suite is designed to test all aspects
               of the DES and is useful for pinpointing specific
               problems.

          o    There is a specification of a maintenance test for the
               DES [11].  The test utilizes a minimal amount of data and
               processing to test all components of the DES.  It
               provides a simple yes-or-no indication of correct
               operation and is useful to run as part of an
               initialization step, e.g., when a computer reboots.

          The use of this algorithm in conjunction with the Symmetric
          Privacy Protocol (see Section 4) is identified by the ASN.1
          object identifier value desPrivProtocol, defined in [4].

          For any SNMPv2 party for which the privacy protocol is
          desPrivProtocol, the size of the private privacy key is 16
          octets, of which the first 8 octets are a DES key and the
          second 8 octets are a DES Initialization Vector.  The 64-bit
          DES key in the first 8 octets of the private key is a 56 bit
          quantity used directly by the algorithm plus 8 parity bits -
          arranged so that one parity bit is the least significant bit
          of each octet.  The setting of the parity bits is ignored.





          Galvin & McCloghrie                                   [Page 9]





          RFC 1446        Security Protocols for SNMPv2       April 1993


          The length of the octet sequence to be encrypted by the DES
          must be an integral multiple of 8.  When encrypting, the data
          should be padded at the end as necessary; the actual pad value
          is insignificant.

          If the length of the octet sequence to be decrypted is not an
          integral multiple of 8 octets, the processing of the octet
          sequence should be halted and an appropriate exception noted.
          Upon decrypting, the padding should be ignored.









































          Galvin & McCloghrie                                  [Page 10]





          RFC 1446        Security Protocols for SNMPv2       April 1993


          2.  SNMPv2 Party

          Recall from [1] that a SNMPv2 party is a conceptual, virtual
          execution context whose operation is restricted (for security
          or other purposes) to an administratively defined subset of
          all possible operations of a particular SNMPv2 entity.  A
          SNMPv2 entity is an actual process which performs network
          management operations by generating and/or responding to
          SNMPv2 protocol messages in the manner specified in [12].
          Architecturally, every SNMPv2 entity maintains a local
          database that represents all SNMPv2 parties known to it.







































          Galvin & McCloghrie                                  [Page 11]





          RFC 1446        Security Protocols for SNMPv2       April 1993


          A SNMPv2 party may be represented by an ASN.1 value with the
          following syntax: