rfc1352.txt

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

       information is not made available or disclosed to
       unauthorized individuals, entities, or processes.

      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.

2.4   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 SNMP 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 SNMP 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 reordering, a
       timestamp value is included in each message generated.
       A recipient evaluates the timestamp to determine if the



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


       message is recent and it uses the timestamp to determine
       if the message is ordered relative to other messages it
       has received. In conjunction with other readily available
       information (e.g., the request-id), the timestamp also
       indicates whether or not the message is a replay of a
       previous message. This protection against the threat of
       message reordering implies no protection against
       unauthorized deletion or suppression of messages.

     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 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 2.4.1 and 2.4.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.

2.4.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 SNMP 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 4) is identified by the ASN.1
   object identifier value md5AuthProtocol, defined in [4].

   For any SNMP party for which the authentication protocol is
   md5AuthProtocol, 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



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


   (see Section 4) is 16 octets.

2.4.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 SNMP 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 5) is identified by the ASN.1 object identifier
   value desPrivProtocol, defined in [4].

   For any SNMP 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.

   The length of the octet sequence to be encrypted by the DES must be



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


   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.

3.  SNMP Party

   Recall from [2] that a SNMP 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 SNMP protocol entity. A SNMP protocol
   entity is an actual process which performs network management
   operations by generating and/or responding to SNMP protocol messages
   in the manner specified in [1]. Architecturally, every SNMP protocol
   entity maintains a local database that represents all SNMP parties
   known to it.

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


      SnmpParty ::= SEQUENCE {
        partyIdentity
           OBJECT IDENTIFIER,
        partyTDomain
           OBJECT IDENTIFIER,
        partyTAddr
           OCTET STRING,
        partyProxyFor
           OBJECT IDENTIFIER,
        partyMaxMessageSize
           INTEGER,
        partyAuthProtocol
           OBJECT IDENTIFIER,
        partyAuthClock
           INTEGER,
        partyAuthLastMsg
           INTEGER,
        partyAuthNonce
           INTEGER,
        partyAuthPrivate
           OCTET STRING,
        partyAuthPublic
           OCTET STRING,
        partyAuthLifetime



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


           INTEGER,
        partyPrivProtocol
           OBJECT IDENTIFIER,
        partyPrivPrivate
           OCTET STRING,
        partyPrivPublic
           OCTET STRING
      }


   For each SnmpParty value that represents a SNMP party, the generic
   significance of each of its components is defined in [2]. For each
   SNMP party that supports the generation of messages using the Digest
   Authentication Protocol, additional, special significance is
   attributed to certain components of that party's representation:

     o Its partyAuthProtocol component is called the
       authentication protocol and identifies a combination of
       the Digest Authentication Protocol with a particular
       digest algorithm (such as that defined in Section 2.4.1).
       This combined mechanism is used to authenticate the
       origin and integrity of all messages generated by the
       party.

     o Its partyAuthClock component is called the
       authentication clock and represents a notion of the
       current time that is specific to the party.

     o Its partyAuthLastMsg component is called the
       last-timestamp and represents a notion of time
       associated with the most recent, authentic protocol
       message generated by the party.

     o Its partyAuthNonce component is called the nonce
       and represents a monotonically increasing integer
       associated with the most recent, authentic protocol
       message generated by the party. The nonce associated
       with a particular message distinguishes it among all
       others transmitted in the same unit time interval.

     o Its partyAuthPrivate component is called the private
       authentication key and represents any secret value
       needed to support the Digest Authentication Protocol
       and associated digest algorithm.

     o Its partyAuthPublic component is called the public
       authentication key and represents any public value that
       may be needed to support the authentication protocol.



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


       This component is not significant except as suggested in
       Section 6.4.

     o Its partyAuthLifetime component is called the
       lifetime and represents an administrative upper bound
       on acceptable delivery delay for protocol messages
       generated by the party.

   For each SNMP party that supports the receipt of messages via the
   Symmetric Privacy Protocol, additional, special significance is
   attributed to certain components of that party's representation:

     o Its partyPrivProtocol component is called the privacy
       protocol and identifies a combination of the Symmetric
       Privacy Protocol with a particular encryption algorithm
       (such as that defined in Section 2.4.2). This combined
       mechanism is used to protect from disclosure all protocol
       messages received by the party.

     o Its partyPrivPrivate component is called the private
       privacy key and represents any secret value needed to
       support the Symmetric Privacy Protocol and associated
       encryption algorithm.

     o Its partyPrivPublic component is called the public
       privacy key and represents any public value that may be
       needed to support the privacy protocol. This component
       is not significant except as suggested in Section 6.4.

4.  Digest Authentication Protocol

   This section describes the Digest Authentication Protocol. It
   provides both for verifying the integrity of a received message
   (i.e., the message received is the message sent) and for verifying
   the origin of a message (i.e., the reliable identification of the
   originator). The integrity of the message is protected by computing a
   digest over an appropriate portion of a message. The digest is
   computed by the originator of the message, transmitted with the
   message, and verified by the recipient of the message.